The link is proving to be unreliable in some cases. However the good news is that retrying is not necessary. The information concerned here is just current status type of information. So as long as we can detect the status packet as being corrupt then we can happily ignore it and wait for the next one. So long as we get a non-corrupt response after a certain number of attempts then everything is fine and dandy.
But if the link is that bad, how are you managing retries etc?
If the link is fundamentally unreliable, then CRC is not the answer IMO.
> What's more, the whole packet's themselves are only a maximum of six bytes long, typically only two or three bytes long (including 1 byte of CRC)!
So how are you sending the length + the data, and how do you know if any bytes have been dropped/inserted by the link?