One semester down, one more to go; how far am I into my Marathon timing project? This post will give an overview of what my system aims to accomplish, and how much is likely to be done.
Electronic timing systems for running often require accuracy of 0.1s, and with typical RFID marathon timing systems, the transponder (tag) is attached to the runner’s (left) shoe, which means that a natural first may be reported as second if there is another runner within a stride’s length who crossed with their left foot, whereas the natural first crossed with their right.
In marathon systems, it’s much easier, as it’s unusual for two runners to cross within this window; yet I wanted to have a backup system, inclase the RFID subsystem failed for whatever reason, which might include tag failure. Part of my projects goals is assurance: how to develop a timing system that participants, officials and sponsors (of participants and officials) can be confident about.
So the first part of my system is what I call the trigger aggregator, this is a microcontroller device (Atmel ATMega8) that integrates with a light sensor as well as a push-button (for manual fall-back and comparison of results). The trigger aggregator is smart enough to detect when the light beam has been broken for an excessive amount of time, and sends a notification that it is unusable. Likewise, the push-button is smart enough to know when it is not plugged in (although at present not smart enough to detect if the wire is broken; I’ll work on that bit later). The events are sent over a serial connection to a controlling computer, which records them with a timestamp.
The second part of the system is the RFID sensor. Thankfully, I’m not designing the antenna itself, but I have been involved with the technology selection process, and will be building the prototype. The technology selection bit was easy: UHF would be preferable due to range, but is prohibitatively expensive; so we basically want HF which has anti-collision features and range of up to a meter, depending on the tag and antenna. Being limited to HF technology, we basically have to go with a RFID-mat on top of which the runners will pass, which is the common design for existing marathon timing events.
I’ve been spending the past few days with a thin laminated disc tag under the inner-sole of my left shoe under the arch of the foot; the idea being to see how suited this position is for the reader. Other options include attaching a tag to the outside (top surface) of the shoe, which may be less reliable. It will be interesting to see how reliable or otherwise the inside-shoe solution works.
Some ISO 15693 RFID kit from APSX was purchased: a RW-310. While this is not something I will likely use in the final solution (at least for the mat, but perhaps for management) it gives me something I can start talking to, which means other parts of my system won’t need to block on the final mat design. Unfortunately, I’m having problems talking to the device: I can send commands, such as Red LED On, and have them work, but I don’t see any indication that it is reading tags or that it returns anything.
The other major parts of the system is the logic of the system, integrating race management processes and processing inputs from the trigger aggregator and RFID to create an output that constitutes the times that each runner finished, and a report that indicates which readings, if any, are ambiguous and should be double-checked by an official. This double-checking can be supplemented by a third possible source, a video camera; however it appears unlikely I will have time to integrate this.
Anyway, I’ll be giving a presentation on all this on Tuesday; an assessable item for the paper I’m doing this for.
One of the more frustrating parts of this project was dealing with the CRC algorithm for ISO 15693, which when compared with the Gold Standard of Obviousness that is CRC algorithms, is very non-obvious, even though I had been given sample code (albeit in Visual Basic). The data-sheet however missed out one important detail (since rectified) in that the first two bytes should not be included in the calculation… Argh! After doing that, it is a fairly simple matter.