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?
.
