Checksums
Many protocols entail checksums to indicate transmission errors. With the checksum feature of URH you can take advantage of that and see if you demodulated and decoded your messages correctly. Furthermore, URH takes care of recalculating checksums when generating manipulated data.
Before we can work with checksums we need to ensure, that we have at least one CHECKSUM Fieldtype (Edit -> Options -> Fieldtypes). By default there is one CHECKSUM Fieldtype called checksum. If you previously installed a version of URH less or equal to 1.6.6 this Fieldtype is called crc.
If you do not have a CHECKSUM Fieldtype simply add one using the ➕ button on the right.
Next, we need a protocol and assign a label to it with the caption of the CHECKSUM Fieldtypes configured before. Consider this example:
Note, that a default checksum is already calculated and compared to the actual content of the label for the selected message. In this case, the checksum does not match -- we need to configure it first!
To enter the configuration dialog you can either
- use the right click menu in protocol label list view on bottom left and choose
Edit Protocol Label - select the label in the central table, right click and choose
Edit Protocol Label [label name]
The following dialog will show up:
In the above table you can configure your labels. As we have a label with type CHECKSUM the advanced settings on the bottom show up. Here we can set the options for the checksum. First you need to choose the category of your checksum. The default is generic, where you can configure a CRC polynomial. If you have a protocol using Wireless Short Packet Standard you can switch category to Wireless Short Packet (WSP) and the checksum configuration becomes this:
This is mostly self-explanatory, so we take a deeper look at the generic category, shown a bit larger in this picture:
In this example we use the predefined CC1101 CRC function. When selecting a CRC function, the CRC polynomial, start value and final XOR will get updated accordingly. Of course, you can edit these values manually if no predefined CRC fits to your protocol.
Last thing we need to configure are the data ranges over which the CRC gets calculated. Often, you will get away with one range. When creating a new label with field type CHECKSUM the start value of the first range will be intially set to:
- End of synchronization label (if any) + 1
- End of preamble label (if no synchroniation label present) + 1
- 0 (otherwise)
The end of the data range will be intially set to the start of the checksum label increased by one.
In this case, the range 17-24 is correct, as it starts behind the synchronization and stops before the checksum label.
Let's close the dialog and see what we get:
The checksum for the first message matches! This is indicated by a green background in the label table at the bottom. If we select a message with a wrong checksum, this is indicated as well:
Note the red background and the calculated "should be 73c6" value.
If you configured CHECKSUM labels in Analysis and drop the according protocol to Generator, it will look like this:
The data inside the checksum is drawn italic. This indicates, that the checksum gets recalculated if you edit data from inside the data range of the checksum label. If we edit nibble 22 of message 4, the checksum gets updated:
