EmbeddedMan
commented
1 year ago The command checksum feature can be turned on by CU,54,1 and turned off by CU,54,0,119 (note that when turning it off, you have to include the proper checksum at the end of the command). When turned on, you're now required to have an extra parameter at the end of every command. This parameter is a 1 to 3 digit decimal number (0 to 255) which represents the "8-bit checksum 2s compliment". In other words, 0x100 - (sum of all commands bytes up to but not including the comma preceding he checksum).
You can use this online calculator to see what your checksums should be: https://www.scadacore.com/tools/programming-calculators/online-checksum-calculator/
Input your command (up to but not including the checksum comma) as ASCII, click AnalyzeDataAscii, then look at the Checksum8 2's compliment value.
Another way to do it is to turn on the checksum feature in the EBB firmware and put in a bad checksum. The error message that the EBB sends back will include what the checksum should be.
For example, if you send SM,1000,1000,1000,0
It will send back !8 Err: Checksum incorrect, expected 153
So you know that the right command and checksum would then be SM,1000,1000,1000,153
If checksums are turned on, and the checksum for a command is missing or incorrect, the command will not be executed and and error message will be returned.
Turning on checksums increases the processing time on the EBB side for each command. I will include a measure of this added time shortly.
The 255 byte maximum command length includes the checksum.
This would be an optional one byte unsigned integer at the end of any command. If present, the EBB will compute the checksum of the command up to that parameter, and generate a new error message indicating a command corruption if the two don't match (and obviously not execute the command). This would allow PC software to have a way of guaranteeing that the command they wanted to send got received properly by the EBB.