-
-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Option to compute and verify checksums (CRC) #111
Comments
Hi - Thanks for the suggestion. Usually when I need a checksum I build it into the driver layer (e.g. Goby ModemDriver) e.g.,
and verify the checksum upon receipt before calling dccl::Codec::decode. That said I can see some utility with adding a checksum as a custom codec in dccl, e.g.
An 8 bit checksum (such as the one you suggested) is pretty prone to missed detections with multiple bit errors (since you have a 1/256 chance to have the same checksum), but that would be an option too (also CRC algorithms tend to be more robust than the NMEA-0183 XOR checksum). To implement the above custom codec ("dccl.crc16"), I'd need to add something to allow the DCCL FieldCodecs to access the full Bitset for encoding and decoding, probably a function like Then the codec itself can throw an exception if the checksum doesn't match upon receipt. It would have to be defined as the last field in the message to be effective. I'll take a look at this if I get bored, though it's not a top priority for me. I'd likely merge this effort with two other somewhat related tasks: 1) implementing #92 and 2) adding a custom codec (e.g. "dccl.descriptor_hash") that does a hash of the current |
Hi!
I am in the process of defining a set of messages and I'd like to add a simple checksum at the "end" of the messages (similar to NMEA0183). Before using DCCL I was using this simple two-byte checksum below:
I am thinking about 📦 ➡️ 📦 wrapping my message (without checksum) into another with checksum so that I can pack it - compute its checksum - and write it. I thought this is quite convolved and maybe there is a better solution. Any suggestions?
The icing on the 🍰 would be to be able to verify (and trust!) the messages received over dodgy 🌊 comms channels.
The text was updated successfully, but these errors were encountered: