Jumbled binary output – known issue?
- 30 July 2015 at 10:27 pm #813Bob CookMember
I’ve written a protocol parser for the binary serial format, and in general I have no problems decoding the stream of DREG_EULER_PHI_THETA packet batches (20 bytes) as well as longer batches such as DREG_GYRO_RAW_XY (44 bytes) and DREG_GYRO_PROC_X (48 bytes). However I’m encountering a problem when sending a GET_FW_REVISION request. I receive its response in the middle of another batch packet. Seems like the UM7 is not properly waiting for the current packet to complete transmission before transmitting the response to the command.
My test program configures the serial port, transmits the GET_FW_REVISION packet, then starts receiving bytes. I get two well formed packets (DREG_GYRO_RAW_XY and DREG_GYRO_PROC_X) then I receive this byte sequence (hex values):
73 6e 70 d4 70 00 68 01 0a ff 3c 00 00 00 00 ff ff 00 73 6e 70 80 aa 55 37 31 43
The first three bytes are correct (snp) then I get PT=d4 giving a batch packet with total length of 20 bytes. Address=70. At this point I should receive 20 data bytes plus two additional bytes for the checksum. But notice that after 13 data bytes I get the “start new packet” sequence (73 6e 70) followed by the reasonable values for the response to the GET_FW_REVISION request. Note that I didn’t show the bytes following the expected 20 data bytes and 2 checksum bytes, but indeed the stream does continue and eventually my parser gets the next “start new packet” sequence and begins to receive valid packets again.
Since this is the last command sent by my test program, subsequent packets are received as expected, no corruption or interruption.
My test program is running on a Mac, using the UM7 + its USB adapter. I’m reasonably confident I’m not getting any data corruption in my hardware setup.
Is this a known issue? If so, what is the workaround suggested?1 August 2015 at 9:18 am #817Caleb ChamberlainMember
That’s very interesting. I haven’t observed that problem directly before, but the Serial Interface does automatically retry if it doesn’t get a response, or if it receives a packet with a bad checksum. And when the Serial Interface does attempt to read the FW revision, it occasionally does receive a packet with a bad checksum. So this may very well be a bug. I’ll look into it.
In the mean-time, make sure that you validate the checksum before accepting a packet, and on bad checksum, request the FW revision again.
- You must be logged in to reply to this topic.