I searched around but didn’t find anything.
I am trying to make a software version of the IFI’s operator interface, does anybody know what the protocol is for the communications between the RC and OI?
this would be great help since if nobody knows i would have to figure it out bit by bit, willing to do it but it takes time.
Thanks for any help!
It is just a serial port sending out a stream of bytes. I dont remember all the details but i did play around with it a few years ago. You can easily figure out what each byte in the stream represents. There is a problem however, there are two checksums which to my understanding are completely unknown as to how they are calculated.
Good Luck
The fact that it carries power might be relevant—it allows IFI OIs to run directly from robots, without external power. In that regard, it’s definitely not a standard serial port.
Maybe IFI will be interested in describing the protocol, now that it is not used on current products. You’d have to ask them, though.
Looked at it today using RealTerm freeware and we see either 26 or 52 byte packets. data is 19.2,8,N,1 Need to look at it with scope to see periodicity and duty cycle to see if it is 26 or 52 bytes every ~26 ms. . I suspect it is 26 bytes even though there is “airtime” at 19.2 for 52 bytes. .
OI --> RC There is a pattern every 26 bytes. With no joysticks plugged in, every packet is the same except 3 bytes that change from packet to packet. One byte is counting and the other 2 bytes are seemingly random. The counter is probably just a packet sequence number scheme to assist in comms stats to determine number of missed packets etc. Possible that the 2 random bytes are CRC16. Will try to use this very cool Java app http://www.macs.hw.ac.uk/~pjbk/nets/crc/ to replicate the CRC from captured data. I wish the java app had used hex instead of binary
If anyone has any info on the IFI OI <–> RC protocol, we would be real interested in hearing about it. Asking IFI about anything like this is generally met with a lecture on secrecy. We could not even get the pinout for the radio port from them.
If we can’t get the IFI protocol reverse engineered, we will likely substitute the VEX CPU for the IFI.
Why you might ask are we messing with this IFI stuff.
We are entering the NURC underwater robotics competition in mid June for our second season. This way we can do all development in LabView. We want to use the ifi RC again in the ROV because the cRIO wont fit and we also don’t want to risk the cRIO in a wet scenario. We do however want to substitute a PC or better yet the cRIO at the operator station. This way we can avoid writing any C code for the RC on the ROV and just use the RC in the ROV as a remotes “sidecar” with digital and PWM I/O and analog I/O.
Frank
Team 0x27
The dashboard specification should help, as it says:
Data packets are sent out the Dashboard port exactly as they are received by the Radio Modem and may contain transmission errors.
It doesn’t define the checksum algorithm, though.
Here is the patent for the control system i found a long time ago when looking to it.
It details the checksums as DCH style checksums. I have no idea to this day what that means. I remember looking for hours and not understanding it 
I even had an excel sheet full of dumps that i was trying to analyze lol
And yeah power can go over the line too but i dont think you have to worry about it. when i was sniffing the data i had a rs232 splitter plugged directly into my computer.
BTW i think that the dashboard protocol and tether protocol are identical. so you can use the dashboard port to try to figure out the checksums
definitely let me know if you figure them out id be really really curious
System_and_method_for_managing_and_contr.pdf (468 KB)
System_and_method_for_managing_and_contr.pdf (468 KB)
Terrific find that patent. It is the missing link. I did not know it existed.
I have a comms/DSP background and BCH stands for the last names of dynamic Trio of Raj Chandra Bose, Dwijendra Kumar Ray-Chaudhuri, and Alexis Hocquenghem. In the late 50’s B and C discovered these codes and about a year later, H did the same or vice versa order of discovery. Now we need to figure out if IFI used one of the known BCH standards. Unfortuantely as I recall these work using syndrome generation though matrix operations and you can fiddle with the generator matrix or one of the vectors and result in an identical (strength ) code to the standard but with proprietary coding (scrambled syndromes) . I really hope that IFI did not get that sophisticated as it might be a real pain to reverse engineer the the proprietary scrambling. We also need to know what data fields of data each checksum operates on and the mapping of that data in the generation the checksums (syndromes per BCH). A good question is if with the 8 bit syndromes, any of the the BCH matrix operations can be reduced to table lookups in the interest of reducing computational effort. Also wondering if they are just using BCH syndromes for error checking or are they actually doing error corrections (FEC).
Besides the BCH, what concerns me as well is the “negotiation” that has to be done between OI and RC prior to the start of telemetry. The transaction diagrams are in the patent but no protocol is detailed for these.
We will play with it some more. Thanks again for the patent lead!!!
removed duplicate post