Closed jveitchmichaelis closed 4 years ago
Sample frame that fails:
b'\x8e\x00\x00\x00\x00\x00\x00\x05\x000\x00\x00\x00\x00\x01\xaf\x9e\x91\x99\xae'
NB
Start frame byte = 0x8E
Channel ID = 0
Bytes 0:3 - sequence number # \x00\x00\x00\x00
Bytes 4:7 - function ID \x00\x05\x000 # nb '0' = 0x30 so this is correct - fpa temp is 0x00050030
Bytes 8:11 - return code # \x00\x00\x00\x00
Bytes 12: - payload (optional) #\x01\xaf
CRC bytes - unsigned 16-bit CRC #\x9e\x91\x99 <--- NOTE should be unstuffed
End frame byte = 0xAE
Seems like we're incorrectly unstuffing only the payload. The payload and crc should be unstuffed together.
Also note: when we escape bytes for sending, we currently only apply it to the payload, not to the CRC. However as this example shows, clearly the camera also escapes values in the CRC. Should probably check whether this is actually the correct behaviour when sending data as well. My gut feeling is that we should escape both and currently this library has no way of sending a value that would trigger this edge case yet so it's not been an issue (I've never seen a CRC fail status)
Noticed this when reading certain FPA temperature outputs with a Boson. I've not investigated what the byte values are - the temperature itself is correct, but the CRC comparison fails. Presumably this is due to an error with bitstuffing (e.g. if there is an escaped character that we're not properly handling). No reason to assume the CRC is actually wrong from the camera, so it's a bug on flirpy's end. Could also be something odd like the CRC itself contains a string that needs escaping?
Might also be that we're exiting the receive loop too early when we think the message is complete (end byte seen) and it's actually not.
Not a critical error for the moment as you can suppress the warnings... but should fix at some point.