Why External Steering Request (XSR) J1939 message has checksum message within the 8-byte Data Field?

Thread Starter


Joined Jan 4, 2017
Camera ECU sends External Steering Request (XSR) J1939 message to the steering ECU. The PGN of this message is 0xF341. There is 4-bit checksum within the 8 byte data field. The SPN of this checksum is 21095.

This 4-bit checksum is used to verify the signal path from the demanding device to the active steering system. It is calculated using the first 7 data bytes, the 4 bit message counter and the bytes of the message identifier.

Since there is 16 Bit CRC Field in the J1939 frame (please see attached), why does J1939 specification include 4-bit checksum within the Data Field? crc_field.jpg


Joined Aug 27, 2009
I can't say specifically for this protocol but in general:
There are packet transmission checks (valid packet) and command valid checks (checksums, counters, secret handshakes, etc for validation of command frame data) to see if the source of the command is sane and not bogus.
Last edited:


Joined Oct 2, 2009
It is not unexpected that a data packet has its own checksum. When encapsulated, the transmitted packet would have is own checksum.


Joined Feb 24, 2006
The CAN CRC is not capable of verifying that the message delivered to the CAN hardware in the transmitter was correctly assembled and delivered to that hardware. Do you have specific objections to redundant checks, or are you just checksum curious?