A few notes on Iditarod dropped dog tracking

I wasn't alone in being quite disturbed by what we learned about Iditarod dropped dog handling and tracking last year, and it seems as if there are opportunities to simplify and improve Iditarod's record-keeping.  At any time (at every time!) it should be possible to know exactly where a given dog is, and to have a list of which dogs are at a given location.  I should emphasize that I do not know how they're currently tracking dropped dogs and some of what I write may be redundant with what they're already doing.

While writing this I found that there's a combinatorial explosion of options and that it would probably be a good idea to summarize up front what I'm thinking.  People who are interested can read on further for more detail.

Requirements and nice-to-haves

What to expect from an automated dropped dog tracking system probably includes

• ease-of-use by checkpoint volunteers, and robust against user errors
• data collected at checkpoints should be available to ITC staff and volunteers who may not be present at the checkpoint - this probably means loading the data into a centralized data store
• but it should also work well with poor or intermittent network connectivity
• it should be relatively inexpensive - Iditarod has a lot of checkpoints and the hardware will need to be available at each. This probably means cheap laptops or netbook computers
• maintainable by volunteers - this means a mainstream development environment if a decision is made to develop a custom solution. Alas, Prolog and APL are out.
• modular - by decoupling input mechanisms from the data store, we can provide multiple input options, or swap in newer technologies as they become available

What are the options?

Here are what I think are workable options:

• Manual transcription of microchip scanner readings into a spreadsheet, using low-cost scanners.  This is error-prone, labor-intensive, and almost certainly the worst option.  However, it's the cheapest, and the least labor up front (the amount of development effort required for a project like this may be a consideration as we start to run out of summer, and time)
• Get a higher-end scanner with a USB interface and software that allows it to scan directly into a spreadsheet (for example, Datamars's ISO MAX V).  This is more expensive than the first option but reduces the effort required of checkpoint volunteers, and is far less error-prone.  Because it's low-effort it's more likely to be done consistently.  It also allows for the possibility of future development on top of what's already being done, in the form of feeding spreadsheet data into a centralized data store automatically.  It also doesn't require much development overhead, although some spreadsheet programming may be required, and someone will have to test and document the process, for two reasons: 1) to make sure that it actually works the way it's believed to work, and 2) to be able to provide direction and support to volunteers
• Get a higher-end scanner with a USB interface and develop a system more closely tailored to Iditarod requirements.  This probably costs about the same as the previous option, but requires custom programming, continuing support and development, etc.  It may be possible to turn this into a class assignment or project for CS students at UAF, although you can expect that the code quality would be inconsistent.  However, if a dropped dog tracking system is to be able to answer both the question of what dogs are at a given checkpoint and where a given dog is, it's going to take some development, whether it's from-scratch or on top of a spreadsheet system.  Note, as well, that documentation for the API (if there is one) or the USB command set (if there's no API) appears to be not easily come by.  This approach could produce the best tools, but it's very high-overhead

Hardware

At this point we'll assume that we'll be identifying dogs by their microchips (dogs are required to be chipped by the rules), which pretty obviously implies a scanner at each checkpoint.  Microchip scanners have displays showing the ID string on the chip, and it's certainly possible to transcribe this manually.  But, we're trying to make it easy for checkpoint volunteers and we absolutely want to minimize errors, and the best way to do this is to have software pull the data off the scanners.  In turn, this suggests that the scanners should have interfaces that allow us to do just that.
I've been taking a look at available scanners and it looks like the most common interface is RS-232 serial interfaces.  And that, right there, is something.  RS-232 hardware used to be standard on nearly all consumer-grade computers - it's what you used to plug your external modem (hey, remember those?) into.  But when was the last time you saw one on a laptop or netbook?  Also, RS-232 can be flaky and difficult to configure (line speed, parity, data formats, etc.).
USB is a much better choice - ubiquitous, works out of the box.  However, are scanners available that have USB interfaces?  As it turns out, yes they are, but I haven't yet been able to find one for less than US $654 (the Datamars ISO MAX V), which is awfully expensive.  Datamars has another scanner that also has a USB interface and is probably less expensive (their Scanfinder XTEND MAX), but I haven't been able to find a price on it.
Microchips are just RFID devices, and microchip scanners are just RFID readers, but documentation of radio characteristics (frequencies, for example) and data formats (plus, some chips are encrypted) are not easily come by.  I would think that a scanner manufacturer would be very, very interested in working with Iditarod on this.  I am also quite sure that there are scanners out there that I haven't looked at and which may meet interface and cost requirements.  More digging is needed.  The primary issue is going to be documentation, or lack of it.  If Iditarod wants to buy microchip scanners and use those as the basis for a dropped dog tracking system, they need to have some very specific questions to take to scanner vendors, and they need to have them in advance of talking to vendors.  This would include a description of the problem that they're trying to solve and requirements and conditions for solving the problem.

I'll talk more about software in a later post.  This one is quite long enough as it is.

SPOT 3 is out!

SPOT has finally released its SPOT 3 device, an upgrade to the SPOT 2.  It addresses some of the limitations of the SPOT Satellite GPS Messenger (aka the SPOT 2) while retaining its strengths.  I think it's still a much better choice for bush travel tracking and emergency signaling than the GPS tracking units that pair with smartphones, like the original DeLorme Inreach (the new generation of which is the DeLorme Inreach Smart Phone) or the SPOT Connect.

Here's what the new SPOT device looks like:

It's got the same basic buttons as the SPOT 2, although the power button has been moved to a location less likely to be pushed accidentally.  It's a hair smaller than the SPOT 2, and a tad lighter.  I like that it now has slots on the frame to make it easier to strap down or otherwise attach to, say, a sled bag (an ongoing headache when using SPOT devices to track sled dog races), a backpack, etc., rather than relying on an external case to hold it.

It's a little more expensive than the SPOT 2, but at $169 still not even close to being as spendy as the DeLorme stand-alone InReach ($299).

New features include

• Settable track rate options, varying from preset intervals of 2.5 minutes to 60 minutes.  This gives better tracking resolution when you want it or better battery life when you're moving slowly or out there for a loooooong time
• Motion-activated tracking.  This is a huge win, since the tracker will stop sending out updates when you haven't moved for awhile.  That is to say, it won't be doing expensive (in terms of power consumption) radio operations.
• Some new, kind of confusing service plans.  The same old $100/year plan is still available, but if you want motion-sensitive tracking (it stops updating if you stay in the same place for awhile) you need to subscribe to the new $150/year plan.  I think this means that you cannot subscribe to the old $100/year plan with a SPOT 3 device, but only with SPOT 1 and SPOT 2 devices.  Don't hold me to that.  Apparently setting the tracking interval to something other than 10 minutes costs extra on top of the $150/year, but I'm not really sure about that.  The plan info is here.

I still think that having a very basic device with a limited user interface and some simple functions is the right approach for wilderness travel or tracking in remote locations.  There are always going to be tradeoffs between function and power consumption, and I'd prefer to err on the side of basic functions and lower power consumption, myself.  For people who use GPS trackers to stay in touch with sponsors, etc., while in remote locations, something like the InReach or even the SPOT Connect makes sense.  But for my own purposes, and for those of many people I know, having a reliable basic tracker and emergency signaling device that doesn't do much else gives a little extra peace of mind.

As a side note, SPOT continues to provide evidence that it's a bad idea to let hardware people write software.  Their website, tracking pages, and device management interface remain hot messes.

I can't find my own SPOT 2 anywhere (I know, right?), and I think I'll be picking up one of these to replace it.

DeLorme update

I haven't been paying much attention to DeLorme's offerings for two reasons:

1. I think having to pair the tracker with a smart phone is a risky strategy in resource-constrained environment (i.e. in the bush for a few days), and
2. the lack of an API meant that you were completely dependent on DeLorme for access to and manipulation of your data

But I recently looked at the DeLorme website and it turns out that they've fixed both problems.  There's a new device, the inReach SE, which launched in April.  The device looks like this:

It's pretty clearly a far more elaborate interface than what's provided by SPOT.  It allows you to compose and send SMS messages (as well as allowing you define some preset messages), and it allows you to receive SMS messages.  It also has an emergency notification button, like SPOT, which sends messages to the GEOS center.  Unlike SPOT it allows you to send arbitrary messages to the GEOS center, as well, so you can answer questions and provide additional information to rescuers.

That said, it uses a rechargeable battery, which I think suggests that DeLorme is somewhat unserious about extended wilderness use.  Disposables, while being wasteful and trashy, are easy to carry and easy to swap in and out as needed.  So that's disappointing, particularly given that the additional functionality in these things is likely to encourage you to run down your batteries more quickly.

As for costs, the device runs $300, and subscriptions are a little spendy.  There's a "Safety Plan," for folks who are using these strictly as an emergency signalizing gizmo (although I think that if that's all you want, you're better off with a SPOT), and it runs $9.99/month with a yearly subscription and renewal requirement.  The other two plans are the "Recreation Plan" ($24.95/month for a yearly subscription) and "Expedition Plan" ($49.95/month for a yearly subscription).  You can also get "seasonal" subscriptions to the latter two plans, with a minimum of 4 months, at $39.95 and $54.95 per month.  These allow unlimited sending of predefined messages and either 40 or 120 messages you compose in the field, as well as unlimited tracking.

As for an API, they're now providing your tracking data through a KML feed.  Contrast this with SPOT's RESTful interface, here.  There are definitely some tradeoffs, although I think on balance the KML feed is a win.  There are a lot of tools out there that already know how to parse and use KML data representations.  At this point I think it's safe to say that we're all tired of XML, but if you're using someone else's tools that issue is largely moot.

SPOT has a very simple JSON format, but still, a lot of folks would like to be able to use their tracking data without having to parse and extract it themselves.  I'd count this as a win for DeLorme.

In looking at the tradeoffs I have to say that I still lean towards SPOTs, ghastly software and all.  I have no interested in tweeting or posting Facebook status updates from the field, the battery issue is pretty annoying, and the additional cost is difficult for me to justify.  I expect that someone who's got sponsors and fans would weigh things quite differently, though.  You have to understand your own priorities and the tradeoffs between the devices when making a choice.