I also just found out from the guys with bigger heads than mine, thatĪlthough this value is required by the listener, it is ignored. However, thanks to Google, I'm slightly more educated on what is going on than I was yesterday. It seems to be working, although I still don't get the same value as the string that works. Private static string GetChecksum( string s)īyte binary = (s) Ĭhecksum = (((checksum ^ 0xFF) + 1) & 0xFF) It is variable length and includes both alpha and numeric charactors. Unfortunately, do to the nature of the industry, I wont be able to include the actuall data in the string.
#Calculate the 9 bit binary checksum calculator code#
If I substitue a good string for a packet that works, and run it through the code above, I get a different value than i'm expecting. It doesn't match what I have for a good packet that works. Private static string GetChecksum(string s)Ģ. I searched around and found the following code: The Checksum is then represented as four ASCII-Hex The Checksum is initially set to zero and is the 16-bit binary addition (excluding parity if applicable) of all characters after, but not including, the SOH character and through (and including) the ETX character. In fact a ushort would be better.Īlso if you work directly with a byte string instead of a character string, and that byte string contains parity on 7 bit characters you may have to exclude it to satisfy the spec (masking it with &= 0x7F).
The routine you have do not exclude the first character (presumed to be the SOH) from the calculation and also it use an int when your spec say to use a short.
0 kommentar(er)
