Dashboard, OI <-> RC Checksum

[Dave Flowerday]

Originally Posted by seanwitte

I thought he was talking about the checksum for the data passed back through the dashboard port.

It's the same thing.

You could use it in a dashboard program to discard invalid packets, for example, making dashboard data more reliable. If you were logging sensor info for instance it would be nice to throw out known bad values.

[Dave K.]

Originally Posted by Dave Flowerday

You could use it in a dashboard program to discard invalid packets, for example, making dashboard data more reliable. If you were logging sensor info for instance it would be nice to throw out known bad values.

Precisely!

On a serial link such as this, especially in the competition environment, bit error rates of 10E-5 wouldn't surprise me. That kind of bit error rate is fine for conveying audio, but crummy for acting on single bits of information.


The relevant documentation for the radio, which appears to be: http://www.electrowave.com/downloads...em_techman.pdf indicates that while the radio is capable of adding its own CRC and discarding errored packets, that there is also an IFI specific mode (RM2000). This is where things get a bit sketchy... the documentation indicates that this fixed length, 26 byte, packet protocol is protected with a CRC, but also appears to indicate that the radio itself is not providing a check, nor discard, of an invalid packet. This is indicated in one table that specifically indicates RM2000 mode provides no CRC check, and a different table shows that RM2000 mode is capable of providing a slightly higher data payload throughput than the CRC protected mode, which indicates less overhead in the on-air protocol.

Given the information at hand, it doesn't seem unreasonable to conclude that errored data will be presented to the OI and RC from the radios, and that the two bytes labeled as 'checksum' in the IFI documentation must be checked for validity before any of the data in the packet should be accepted.

Therefore, for those of us that might want to create a more useful representation of a portion of that data stream for our drivers during the competition, in order to work directly with that data we must know that the data we are acting upon is actually valid.

Speaking (writing?) as someone who has, for more years than I want to admit, worked with serial data that is conveyed via radio, this is just one of those things that experience tells me this is something I must do if I want to use the data for something beyond simple debugging via the provided dashboard utility.

So for those that weren't aware of this potential pitfall... well, now you know.

In as much as I'm happy to share the results of anything I come up with, I thought I'd try the logical approach first... and just ask.

Thanks,