Dashboard, OI <-> RC Checksum

[Dave K.]

Hi,

After searching the forums I see that this question has come up over the years, but nobody seems to have an answer as to the "propriatary" method IFI uses to compute the 26 byte packet checksum on the OI to RC data link.

Given everything else that seems to be documented, it seems odd that this would be considered a "secret" and withheld.

Before I dig into it myself, has anyone already reverse engineered this and if so are you willing to share?

Thanks,

[seanwitte]

It seems like a waste of time to reverse engineer a useless piece of information. Is there a particular reason other than curiosity?

[Dave Flowerday]

Originally Posted by seanwitte

It seems like a waste of time to reverse engineer a useless piece of information.

I wouldn't say useless. Useless during a match, perhaps, but there's some non-competition things that can be done. For example, in 2002 we built a miniaturized controller that plugged directly into the tether port on the robot and simulated an OI. It had just a couple of toggle switches on it to allow us to move the powered hooks on our robot. It was intended to be something that the drivers could carry in their pocket and take out on the field at the end of the match to unhook the robot from the goals without having to set up the whole OI and tether up. We ended up not using it during actual competitions but it was a neat little project.

I should find it and take a picture of it.

[seanwitte]

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

[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,

[Dave K.]

Originally Posted by Dave Flowerday

I wouldn't say useless. Useless during a match, perhaps, but there's some non-competition things that can be done. For example, in 2002 we built a miniaturized controller that plugged directly into the tether port on the robot and simulated an OI. It had just a couple of toggle switches on it to allow us to move the powered hooks on our robot. It was intended to be something that the drivers could carry in their pocket and take out on the field at the end of the match to unhook the robot from the goals without having to set up the whole OI and tether up. We ended up not using it during actual competitions but it was a neat little project.

I should find it and take a picture of it.

Dave,

Now that's pretty cool, I hadn't even thought of something like that. Given that the FIRST rules are fairly explicit about not permitting ancillary circuits in output paths, your teams solution was quite elegant.

In any event, how about taking a picture of the relevant portion of the code that would have had to have computed the two check bytes ;-)

Thanks,

[Danny Diaz]

Originally Posted by Dave K.

Given everything else that seems to be documented, it seems odd that this would be considered a "secret" and withheld.

It doesn't seem odd at all. The proprietary checksum is the one piece of the puzzle that makes everyone as sane as they are - if the checksum generation wasn't proprietary, anyone could send additional packets from anything. Think about it, anyone with an RS-485 port and a transmit radio could send packets out that LOOK like they're coming from your OI. Could you imagine the ramifications of that? Even with "Gracious Professionalism", could you imagine the perceived ramifications of that?

Of course, on the other hand there is the benefit of being able to turn your laptop into an OI, provided it's fast enough to handle the real-time processing of the packet information - from what I hear (from IFI) it's pretty demanding. However, I've been promised that we won't be seeing the checksum algorithm any time soon, and they've specifically asked those who are capable to NOT attempt to determine how that checksum is created.

-Danny