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