Managing resources during Public Service events using APRS

Over the weekend I helped support the American Diabetes Association Tour de Cure; a two-day charity bicycle ride that allows riders to choose between 80 and 100-mile courses each day. I’ve been supporting this ride for many years now, and, thankfully, we’ve been using the same route for the last few years which makes it easier to come up with a communications plan each year.

Over the years I’ve watched other people’s techniques for managing resources.  One guy kept his notes on a knee board and used some sort of shorthand notation that no one could figure out during the brief glances we were allowed.  In years past I’ve enjoyed using a small whiteboard to keep track of where my Support and Gear (SAG) vehicles were. This year, however, I decided to do something a little different.

The Goal

The goal of my madness is to make sure I had SAG vehicles “patrolling” between rest stops where we knew bicyclists were located.  The Raleigh Tour de Cure has six rest stops with those doing 100 miles doing a loop that takes them back through rest stops five and six before heading to the finish.  Altogether, there are eight segments of race course that need to be covered.  Each SAG is assigned a segment to run in a particular direction.  In this way, it is hoped that a SAG will go past a certain point every ten to fifteen minutes (we don’t want a rider to have to wait a long time for a SAG).  Luckily not all eight segments are occupied at the same time which reduces the overall need.  This year we managed to do it with five SAGs, one doctor, one motorcycle SAG (who also had a photographer riding backwards taking pictures of the riders for MotoPhotoMe), and two shadows.  We could have used more but this is a great crew, and everyone worked together as a team flawlessly.

Past Management Tool

Like I pointed out earlier, I used to use a whiteboard to keep track of who was where and to make assignments when a SAG made it to their next rest stop.  My chart looked something like this:

 RS  | SAG
--------
S->1 | 1↑, 2↓, Last Rider
1->2 | 3↓
2->3 | 4↓, First Rider

This means that between the Start and Rest Stop 1 I have SAGs 1 (running backwards from 1 to the Start) and 2 (running forwards from the Start to 1), between Rest Stops 1 and 2 I have SAG 3, and between Rest Stops 2 and 3 I have SAG 4.  I try to stagger SAGs going between the same rest stops to add patrol coverage.  When SAG 1 reaches Rest Stop 1 the expectation is that they will call me on the radio and let me know they’ve arrived.  I will then give them a new assignment (it could be patrolling back towards the Start line or moving on to Rest Stop 2).  A
whiteboard makes it easy to make these updates and keep everything in order.

The benefits of using such a system is that it’s simple and easy to manage, allows a quick look to see your needs for coverage, and allows you to make other notes (e.g. who has already had lunch, special assignments, where is the lead and last riders).  The drawback is that there is no record keeping with this system.  You can’t go back and see who was where when.  Keeping up with this information would require a completely separate form and would likely slow you down.  Also, because all this information lives locally on a whiteboard there is no way to
share this information with anyone else if, for example, you need to step away from the radio for a few minutes.

Using APRS to manage the resources

This year I decided to use my APRS client, Xastir, to manage my resources.  Some of the SAGs ran APRS trackers (thanks to the Raleigh Amateur Radio Society (RARS) for letting us use their trackers!) in their vehicles which meant I didn’t have to update their locations and I always knew where they were.  The other resources I had I simply used objects on the map to track where they were located (approximately) and moved those objects when they provided an update.  It looked something like this:

I could also put requests for service on the map (e.g. bicyclists that had contacted us via phone or SMS to say they needed assistance) and be reasonably sure I was sending the closest SAG to them.

Because I was the only consumer of this data (this year) none of the objects I created were actually sent over the air or to the Internet.  I could have easily shared this information over the air or the Internet to others and I hope to do so in the future.

Oh, I should point out that one of the SAGs, Moto 1, used APRSDroid on his cellphone to provide his location.  This was problematic as there were many places along the route that didn’t have any cellular connectivity much less sufficient data connectivity.

We also didn’t have sufficient APRS infrastructure to cover the entire route.  This was mostly remedied by the addition of a tactical digipeater.  I’m hoping to establish a new permanent digipeater along the route in the future.

What other benefits can APRS bring to the table?

Beyond keeping track of everyone’s location, either in semi-real-time or by moving objects around the map, APRS can provide information sharing to other stations that need to know what’s happening.  By pushing objects to the network, one can inform all participants of resources and needs (this requires some sort of display to consume this information). Also, the voice frequency can be kept clear of routine requests by using the text messaging capabilities of APRS.

Record keeping can be done in a not-so-detailed way by having the APRS client record all traffic to disk.  This means that every movement, addition or deletion of an object, and every message would be recorded.  While not as detailed as formal messages, or even keeping a detailed log, it does provide some tracking that, if needed, might be helpful.

Conclusion

Using APRS to manage public service events could prove to be helpful.  It doesn’t necessarily require buy-in from everyone involved but would benefit from others participating.  I didn’t go into all the features that APRS could bring to the table but, rather, touched on the ones that
I felt were important.  I’m hoping to extend this article in the coming months to bring more thoughts on the subject.

Thanks

I’d like to thank the volunteer hams that came out and participated in this two-day event:

John Snellen, AI4RT – SAG 1
RARS Public Service Coordinator

Wallace Smith, KJ4UKV – SAG 2

David Krum, NW3U – SAG 3

Joe Sheets, KJ4LZM – SAG 4

Bruce Buck, KC4UQN – SAG 5

Tom Byrum, N3TCB – Moto 1

Lubov Byrum, N3BOV – Photo 1

Dr. Scott Playford, KM4NWC – Doc

Bill Cole, KG4CXY – “Jim”
founder of Carolina Helping Hams

Mark Freeze, WD4KSE – “Zoe”

Notes

• Yes, I realize all the maps used in this article don’t contain roads and such.  While this information was available to me I really didn’t need it as I had the route and rest stop data staring at me.  If I needed the road-level maps they were just a couple of clicks away.
• The APRS network frequency, 144.390MHz, is quite busy and I wonder if building a separate network on a different frequency would benefit the event.  Think ALOHA.