[yoyodyne]

I have collected more data on the camera's reaction to inserted bytes and of course it depends on where they are inserted. In the attached dump a zero was inserted as the third byte of the Virtual Window and the camera actually ACK'd the command but was not happy subsequently.

What the attached file shows is the output from an RS-232 snooping program (wSHDCOM) that collected CAMERA (com1 real serial port) and RC (com4 USB adapter) data at the same time. Because of the PC serial port buffer timing it takes a little work to unravel the actual sequence of events...

In the packets in sequence section, the actual time offset from the previous packet is shown. As you can see, the camera normally acks a command almost immediately. One interesting thing is that after a TC command is received, the camera outputs an ACK and the FF immediately and then spends 63ms or so processing the T-Packet data. I expected that the FF would be connected to the T-Packet not the ack timing wise. Of course, the time it takes the RC to respond to Camera Ack or a T-Packet depends on how long until the next 26ms loop hits at least for us.

If our code does not hear from the camera in 1000ms we just set "camera_initialized" back to zero - which is not elegant but does the trick until the RC hickups again and transmits a random zero.

The good news, if there is any is that the RC does not transmit a random zero for a long time (typically 4) minutes after a power cycle. My worry is that the camera comms could take a hit before autonomous actually begins if there are delays in getting the field going.

I would really like to hear from anyone that has a theory as to why the serial port is inserting zeros - if we could fix that I would sleep much better!

Greg