Having been in the hobby for a few years now, I usually see myself enjoying building things more than flying/using them. Here in Albuquerque we have a very active RC enthusiast group called Southwest Pod Racing. Racing has always been the main motivation for most of the people that join our group. Before timing systems were as widespread as they are now, our racing consisted mostly of going around trees and watching who finished first. As the skill level increased, so did the number of close finishes. So now, after joining MultiGP we acquired a gate a timing system that completely changed the way we fly.
The two main sources that I have seen in the multi-rotor world for timing systems was Trackmate Racing and I-LapRC Race Timing System. Having looked at both transponders up close, they appeared to have mostly the same hardware. So, I wanted to take a closer look at how they work so that in the future I may be able to make something of my own and have interoperability between the devices. The first device I looked at was the Trackmate Racing Transponder
- ATtiny25 8-bit AVR RISC-based microcontroller
- Fox Electronics 7.3728MHz ±30ppm Crystal
- 3.3V Switching Regulator
- 940nm IR LED
- Reverse Polarity Protection Diode
Typical IR protocols use a 38kHz carrier frequency. First thing I did was to put this on the scope and noticed that it was around 460kHz. I believe the standard IR carrier to be 455kHz, so this was close enough.
I started by taking some notes by hand to get an idea of the protocol used. Taking a glace at the capture it looked to be UART communication and judging by the Crystal selection, was operating at 38400 buad (8N1). This in fact proved to be true.
The transponder I looked at had an id of “3420” listed on the front. I started by decoding the data that was being sent.
Carrier present is “0” and idle is “1”, then the bit is:
Grouping the bits into UART-style framing with a “0” start bit, eight data bits, and a “1” stop bit, you have:
0 10110000 1
0 00111010 1
0 10001001 1
0 10100110 1
… followed by idle, a valid state.
UART data is sent LSb first, so reverse the bits in each byte and the data becomes:
b00001101 = 0x0D
b01011100 = 0x5C
b10010001 = 0x91
b01100101 = 0x65
Notice that 0x0D5C is decimal 3420. I had a feeling that the other two bytes would be some sort of CRC checksum in order for this to handle the likely errors it would get. Figuring out the CRC algorithm was my next task.
Reversing CRC Checksum
The hard part about reversing a CRC is that there are so many that exist and even many different polynomials that could be used for the calculation. I searched around and found a handy tool called CRC RevEng that really made this process easy. This tool is “an arbitrary-precision CRC calculator and algorithm finder”. Gathering up a few transponders and using this tool, I came up with the following results:
- Poly 0x1021
- Initial state 0xFB1A
- XORout 0x0000
This appears to be a slight varient of the XModem CRC that is commonly used. Using these options, calculated the checksum for “0x0D5C” to be “0x9165”. Verified on many other transponders that the same options for the crc calculation holds true. There are many freely available libraries for your language of choice. In the short term it’s easy to use an online CRC calculator like this one fromsunshine2k or you can just use RevEng to calculate it for you.
So, for Trackmate Racing transponders, data is sent LSB via 38400 UART with the first two bytes being the tag-id and the second two bytes being a 16-bit checksum.
The code I wrote was pretty crude and lacks proper timing, and I ended up tweaking things while watching the scope. Could probably share this too.
I have this done, just need to add here