Checksum Specification

<< Click to Display Table of Contents >>

Navigation:  Reference >

Checksum Specification

Checksum specifications are used in Edit Send Sequence and Edit Receive Sequence dialogs and in the Docklight Scripting method CalcChecksum. See Calculating and Validating Checksums for a general overview.

 

Supported Checksum Specifications  / checksumSpec Argument

 

checksumSpec

Checksum algorithm applied

MOD256

8 bit checksum: Sum on all bytes, modulo 256.

XOR

8 bit checksum: XOR on all bytes.

CRC-7

7 bit width CRC. Used for example in MMC/SD card applications. An An alternative checksumSpec text for the same checksum type would be:

CRC:7,09,00,00,No,No

See the "CRC:width, polynomial..." syntax described in the last row.

CRC-8

8 bit width CRC, e.g. for ATM Head Error Correction. Same as:

CRC:8,07,00,00,No,No

CRC-DOW

8 bit width CRC known as DOW CRC or CCITT-8 CRC. Can be found in Dallas iButton(TM) applications. Same as:

CRC:8,31,00,00,Yes,Yes

CRC-CCITT

16 bit width CRC as designated by CCITT. Same as:

CRC:16,1021,FFFF,0000,No,No

CRC-16

16 bit width CRC as used in IBM Bisynch, ARC. Same as:

CRC:16,8005,0000,0000,Yes,Yes

CRC-MODBUS

16 bit width CRC as used in MODBUS. Similar to CRC-16, but with a different init value. Same as:

CRC:16,8005,FFFF,0000,Yes,Yes

CRC-32

32 bit CRC as used in PKZip, AUTODIN II, Ethernet, FDDI. Same as:

CRC:32,04C11DB7,FFFFFFFF,FFFFFFFF,Yes,Yes

-MOD256

Similar to MOD256, but returns the negative 8 bit result, so the sum of all bytes including the checksum is zero.

CRC:width, polynomial, init,

finalXOR, reflectedInput,

reflectedOutput

Generic CRC calculator, where all CRC parameters can be set individually:

width : The CRC width from 1..32.

polynomial : HEX value. The truncated CRC polynomial.

init : HEX value. The initial remainder to start off the calculation.

finalXor : HEX value. Apply an XOR operation on the resulting remainder before returning it to the user.

reflectedInput : Yes = Reflect the data bytes (MSB becomes LSB), before feeding them into the algorithm.

reflectedOutput : Yes = Reflect the result after completing the algorithm. This takes places before the final XOR operation.

 

Remarks

 

Each of the predefined CRC algorithms (CRC-8, CRC-CCITT, ...) can be replaced by a specification string for the generic CRC computation (CRC:8,07,00...) as described above. We have carefully tested and cross-checked our implementations against common literature and resources as listed in the CRC Glossary.

 

Unfortunately there are a lot of CRC variations and algorithms around, and choosing (not to mention: understanding) the right CRC flavor can be a rather difficult job. A good way to make sure your CRC calculation makes sense is to run it over an ASCII test string of "123456789". This is the most commonly used testing string, and many specifications will refer to this string and provide you the correct checksum the CRC should return when applied on this string.

 

Checksums in Edit Send Sequence  /  Edit Receive Sequence

 

In the Checksum tab, choose one of the predefined definition strings from the drop-down list, or type in your own definition in the following format:

 

[ (startPos, len) ] checksumSpec [A or L] [@ targetPos] [ # optional user comment]

 

with anything inside [ ] being an optional part.

 

Part

Description

checksumSpec

Required. String that specifies the checksum algorithm and its parameters, according to the checksumSpec Format table above.

(startPos, len)

e.g.

(1, 4)

Optional. Start and length of the character area that is used to calculate the checksum. By default everything before the checksum result is used.

A

Optional. If used, the resulting checksum value is converted into a readable ASCII text. This is for example used in MODBUS ASCII protocols.

L

Optional. Little Endian - the resulting checksum value is stored with the least significant byte (LSB) first. Default is Big Endian / MSB first.

@ targetPos

 

e.g.

@ -4

Optional. Specifies the first character position for storing the resulting checksum value.

By default Docklight places the checksum result at the end of the sequence data, unless you have specified "A" for ASCII result. In this case, the results is stored one character before the end, so there is still space for a "end of line" character, typically a CR as in MODBUS ASCII.

# comment

You can type in a comment about this checksum specification

 

Remarks

 

startPos, len and targetPos support negative values, too, as a way to specify positions relative to the end of the sequence and not relative to the start of the sequence. Examples:

startPos is -4 : start calculating at the 4th character from the end.

len is -1 : use everything until the end of the sequence.

targetPos  is -1 : first (and only) byte of the result is stored at the last sequence character position.

targetPos  is -2 : result is stored starting at the 2nd character from the end.

targetPos  is -3 : result is stored starting at the 3rd character from the end.

 

Examples

 

# (off, no checksum)

MOD256 # simple one byte sum on all but the last character"

CRC-MODBUS L #  MODBUS RTU checksum. Lower Byte first ('Little Endian')

CRC-MODBUS A @ -5 #  MODBUS ASCII checksum returned as text

(1,3) CRC-16 @ 10 # CRC-16 checksum over the first 3 bytes.

(2, -5) CRC:8,07,00,00,No,Yes # CRC with custom, non-standard spec.