Skip to content

Commit

Permalink
Have main script die with error in case we fail so we can capture thi…
Browse files Browse the repository at this point in the history
…s in our start-up script and handle it, such as reverting to a known-good config file, such as an iCal query failed or some other temporary issue. Updated dw-start example script to match.

Cleaned up README file a little.
  • Loading branch information
khaytsus committed Jul 18, 2016
1 parent 9874de4 commit 49d5e94
Show file tree
Hide file tree
Showing 3 changed files with 17 additions and 7 deletions.
10 changes: 6 additions & 4 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ This script is based on the ideas from Bob Bruninga (WB4APR) in http://www.aprs.

### aprsobjects.pm

You will need to update aprsobjects.pm with the settings and method you wish to use to define objects. If you want to use iCal you must set up an iCal calendar and set the public URL for it, or you can define the objects using the @objects array. To set up iCal see the second below specific to that topic.
You will need to update aprsobjects.pm with the settings and method you wish to use to define objects. If you want to use iCal you must set up an iCal calendar and set the public URL for it, or you can define the objects using the @objects array. To set up iCal see the section below specific to that topic.

#### Default options

Expand All @@ -24,7 +24,7 @@ There are several defaults to set in the get_defaults function
* To ensure our module fields matches our program fields, this must match the version in the main program. This just indicates the need to ensure any fields you have defined still meet the fields the program needs.

* $ical = "https://calendar.google.com/calendar/ical/....../basic.ics";
* iCal url when using iCal as a data source for objects. Disables the use of using the @objects array in aprsobjects.pm
* iCal url when using iCal as a data source for objects. Disables the use of using the @objects array in aprsobjects.pm If you do not want to use iCal as a source, set this to an empty string or to undef

* $startinterval = '0:30';
* How long to delay our initial beacon advertisement, in direwolf format (min:sec). In this example, it means Direwolf will wait 30 seconds before it advertises the first object.
Expand All @@ -37,6 +37,8 @@ There are several defaults to set in the get_defaults function

#### Objects array

The @objects array is how you define the APRS objects you want to advertise. If you're using iCal there is no need to populate anything in this object.

* Objects array is a pipe (|) separated list of fields
* Leave empty for unused field, ie: |data|data||data|data
* General Formatting is whatever Direwolf requires for the given field, see examples, Direwolf docs, etc
Expand Down Expand Up @@ -65,15 +67,15 @@ There are several defaults to set in the get_defaults function

Setting up APRS objects in the @object array can be a bit tedious and requires someone editing the file. Using an iCal URL as a data source is potentially an easier way to define objects, and this also allows you to delegate the adding and maintaining of objects to other people as you can share your calendar with other users. I have tested this with Google Calendar but it should work with other calendars as well. Be aware that this data is pulled down every run, and can take several seconds to download and parse. If you need your data to not require an internet connection it is better to use the @objects array.

I have found that a dozen APRS object events with recurring settings can take a long time to parse, so the script limits the days evaluated to today and tomorrow (as events are dated as UTC, events in the evening may be dated tomorrow in the raw iCal data that is parsed). This speeds up the parsing considerably and since we're only generally advertising for events in immediate future this is fine. When limited to this timeframe I generally see the script take about 11s to run on a busy Raspberry Pi 2 on a day with 7 APRS objects defined but takes less than 1s on a modern desktop machine.
I have found that a dozen APRS object events with recurring settings can take a long time to parse, so the script limits the days evaluated to today and tomorrow (as events are dated as UTC, events in the evening may be dated tomorrow in the raw iCal data that is parsed). This speeds up the parsing considerably and since we're only generally advertising for events in the immediate future this is fine. When limited to this timeframe I generally see the script take about 11s to run on a busy Raspberry Pi 2 on a day with 7 APRS objects defined but takes less than 1s on a modern desktop machine.

#### Calendar Setup

Nothing really special to do for the Google Calendar setup, you can name it anything you want. But to get the URL, you'll need to go to your APRS calendar's settings and either use the Public address if you have made this calendar public, or use the Private address. Copy the URL and put it into the $ical variable in the get_defaults function in aprsobjects.pm Just click the appropriate ICAL button in Google Calendar settings and copy the link it gives you. You can see an example URL that I have set up in the file to sanity check that your URL looks right.

#### APRS Object calendar entries

When you create calendar entries for your APRS objects you can set the event title to anything you want, this value is not used by this script. If the event repeats or is an all day event (ie: A repeater, etc) select those options. The Description is where the required fields are defined and must be set up correctly or the object won't be properly parsed. The order of the options does not matter but they must be in the format of FIELD:DATA and separated by a new line. These are the same fields used in the objects array, so for more details on exactly what the fields mean please see that section. Example:
When you create calendar entries for your APRS objects you can set the event title to anything you want, this value is not used by this script. If the event repeats or is an all day event (ie: a repeater, etc) select those options. The Description is where the required fields are defined and must be set up correctly or the object won't be properly parsed. The order of the options does not matter but they must be in the format of FIELD:DATA and separated by a new line. These are the same fields used in the objects array, so for more details on exactly what the fields mean please see that section. Example:

TIMEBEFORE:15
OBJNAME:IRLP-4945
Expand Down
3 changes: 1 addition & 2 deletions aprs.pl
Original file line number Diff line number Diff line change
Expand Up @@ -212,8 +212,7 @@ sub ical_parse {

my $file = get($url);
if ( !defined($file) ) {
print "\n## iCal download failed (check URL?)\n";
return;
die "\n## iCal download failed (check URL?)\n";
}

my @returnobj;
Expand Down
11 changes: 10 additions & 1 deletion dw-start.sh
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,7 @@ if [ $pid -gt 0 ]; then
killall direwolf
sleep 5
else
echo "Config files match, exiting"
echo "Config files match, exiting dw-start script"
exit
fi
fi
Expand All @@ -35,5 +35,14 @@ fi
mv $config ${config}.bak
cat $template >$config
perl aprs.pl >>$config

# Check our return code; if it's non-zero let's revert to our previous config file
rc=$?

if [ $rc != 0 ]; then
echo "APRS Script failed, reverting"
mv ${config}.bak $config
fi

# Start Direwolf
/usr/local/bin/direwolf -t 0 -c $config >/opt/direwolf/logs/direwolf.log

0 comments on commit 49d5e94

Please sign in to comment.