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.