You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, thank you for your library, it is very helpful!
It just lacks documentation to fully understand capabilities and usage (more than the simples examples provided), for example, the COBS stuffing on the start byte value is not well described until you read the Packet::stuffPacket or Packet::unpackPacket (I first used some COBS code for '0' value in my C# application until I understood why it was not working).
Nevermind.
If I'm not wrong, the CRC byte is computed on the payload bytes only (after COBS encoding).
But what if some other bytes are corrupted?
I mean, if the COBS overhead byte is corrupted, CRC checking will succeed, but the COBS decoding will fail and will give unpredictable results.
What if the ID byte is corrupted? CRC and COBS will succeed (if there is no other corruption of course) and will give an unpredictable result depending on the ID usage in our software.
Why not compute the CRC byte on the whole bytes from ID to end of payload? The start byte can't be corrupted or reception is not possible, the stop byte can't be corrupted or the reception will be canceled so there's no need to check those bytes.
It's very unlikely to have only one of those 2 bytes corrupted, but the CRC checking is to ensure no byte is corrupted, I wonder why not include those bytes.
The text was updated successfully, but these errors were encountered:
Additionally, doing a CRC check on ID, COBS and size bytes could give the ability to send void payloads and still be able to CRC the message where only ID is the useful data like requested here: #88
First, thank you for your library, it is very helpful!
It just lacks documentation to fully understand capabilities and usage (more than the simples examples provided), for example, the COBS stuffing on the start byte value is not well described until you read the Packet::stuffPacket or Packet::unpackPacket (I first used some COBS code for '0' value in my C# application until I understood why it was not working).
Nevermind.
If I'm not wrong, the CRC byte is computed on the payload bytes only (after COBS encoding).
But what if some other bytes are corrupted?
I mean, if the COBS overhead byte is corrupted, CRC checking will succeed, but the COBS decoding will fail and will give unpredictable results.
What if the ID byte is corrupted? CRC and COBS will succeed (if there is no other corruption of course) and will give an unpredictable result depending on the ID usage in our software.
Why not compute the CRC byte on the whole bytes from ID to end of payload? The start byte can't be corrupted or reception is not possible, the stop byte can't be corrupted or the reception will be canceled so there's no need to check those bytes.
It's very unlikely to have only one of those 2 bytes corrupted, but the CRC checking is to ensure no byte is corrupted, I wonder why not include those bytes.
The text was updated successfully, but these errors were encountered: