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



Checksum algorithm applied


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


8 bit checksum: XOR on all bytes.


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


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


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



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



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



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



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



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





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

This is equivalent to what is known as LRC (Longitudinal redundancy check) used e.g. in POS applications.


Like -MOD256 / LRC, but it expects the source data to be HEX numbers as readable ASCII text. See the MODBUS ASCII example below.

CRC:width, polynomial, init,

finalXOR, reflectedInput,


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.




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.





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

(startPos, len)


(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.


Optional. If used, the resulting checksum value is converted into a HEX number as readable ASCII text. See the MODBUS ASCII example below.


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

@ targetPos



@ -4

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

By default Docklight writes the checksum result to the last  sequence data positions, 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




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.





Checksum Specification

Send Sequence Example

Actual TX Data


# (off, no checksum)

01 | 02 | 03 | 04 | 05 | 00

01 02 03 04 05 00

after a # you can type in any comment to describe your checksum

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

01 | 02 | 03 | 04 | 05 | 00

01 02 03 04 05 0F

As a checksum placeholder, an extra 00 was added, but you can use any value from 00-FF.

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

01 | 06 | 01 | 02 | 00 | 07 | FF | FF

01 06 01 02 00 07 68 34

CRC-MODBUS is a 16 bit checksum which is placed at the last two character positions in the sequence data by default.

(2, -5) LRC-ASCII A @ -4
# MODBUS ASCII checksum is LRC over readable HEX data, excluding start ':' and end 'CR/LF'

: | 1 | 1 | 0 | 3 | 0 | 0 | 6 | b | 0 | 0 | 0 | 3 | X | X | r | n



LRC-ASCII treats the sequence data as a readable HEX string, where each data byte is represented by two characters.

Using the A option produces a readable 2-letter checksum text, instead of a one character result.

The @ -4 places the result at the 4th character position from the right (leaving the trailing CR / LF intact).


# CRC with custom, non-standard spec

01 | 02 | 03 | 04 | 05 | 00

01 02 03 04 05 3D

Rare or custom CRCs flavors can be calculated by Docklight, but you need to know the required CRC calculation parameters. For more details see the resources listed in the CRC Glossary.