Attached is External Brake Request(XBR) J1939 message checksum calculation. SAE J1939 Digital Annex(DA) specifies this checksum algorithm. The result of the calculation is 4-bit checksum.

Why is checksum right shifted by 4 bits and added to checksum? Why not just take 4 least significant bits of the checksum? Another words, why not just add first Seven data bytes + message counter + CAN ID and take 4 least significant bits of this result?

 

I don't know anything about CAN and SAE protocol so I can't help very much.

I found the same info here:
https://www.vector.com/in/en/know-how/protocols/sae-j1939/#c94570

CRC is computed, as usual, from a LFSR (see polynomial , seed and XOR mask - the + sign should represent an XOR). Your question is related to the rule C.

Why 4 bits? I don't know. The information provided by the link is not so detailed and well formatted in my opinion. It seems that the message ID is the interesting part.

The standard shoul be the reference document.

 

Attached is External Brake Request(XBR) J1939 message checksum calculation. SAE J1939 Digital Annex(DA) specifies this checksum algorithm. The result of the calculation is 4-bit checksum.

Why is checksum right shifted by 4 bits and added to checksum? Why not just take 4 least significant bits of the checksum? Another words, why not just add first Seven data bytes + message counter + CAN ID and take 4 least significant bits of this result?

Without that, no error in the upper nibble of any data element could be detected.

Consider a base ten example in which we have four digit numbers with each pair of digits playing the role of a nibble. To keep things simple, let's just use two data values covered by the checksum.

data1 = 7649
data2 = 3784

data1 + data2 = 11433 => 1433 (the carry out of the MSD is lost)

Now we keep the two least-significant digits as our checksum.

CHK = 33

So our data packet becomes: 7649378433

This is transmitted, but instead of 3784, it is received as 3584.

What is the expected checksum?

7649 + 3584 = 11233 => 1233 => 33

Checksum passes.

But now, let's add the upper and lower halves of the check sum and keep the least two digits of the result.

Original data sum = 11433 => 1433 => 14 + 33 = 47
Received data sum = 11233 => 1233 => 12 + 33 = 45

Checksum fails.