I have a requirement where i have to implement end - to - end protection mechanisms, like checksums on application level to protect data from corruption during transmission. How do I need to do this? What are the common check sum mechanisms i can use?

 

I have a requirement where i have to implement end - to - end protection mechanisms, like checksums on application level to protect data from corruption during transmission. How do I need to do this? What are the common check sum mechanisms i can use?

Lot's of ways to go about that. CRC's are popular because of their speed and robustness. Wikipedia does a pretty good job of covering the basic approach here. In general though, any function which maps a large set of bits to a smaller set and exhibits fairly optimal collision-resistance and "avalanching" (small changes in the data leading to vastly different hash codes) could work.

Of course many protocols already have some sort of error-correction built in. Are you sure that you actually need it? How is the data being transferred?

 

Thank you for the reply. I am communicating over CAN bus. So when i am sending data i want to use the checksum calculation and the receiving end can make sure that the data is correct.

 

I am communicating over CAN bus. So when i am sending data i want to use the checksum calculation and the receiving end can make sure that the data is correct.

See section 1.2.2 of this document:

Error Handling

CAN implements five levels of error detection. At the message level, it performs cyclic redundancy checks,
frame checks and acknowledgment checks. Bit level checks consist of monitoring and stuffing.

Cyclical redundancy errors are detected using a 15 bit CRC computed by the transmitter from the message
content. Each receiver accepting the message recalculates the CRC and compares it against the transmitted
value. A discrepancy between the two calculations causes an error flag to be set. Frame checks that will flag
an error are the detection by a receiver of an invalid bit in the CRC delimiter, ACK delimiter, EOF or 3-bit
interframe space. Finally, each receiving node writes a dominant bit into the ACK slot of the message frame
that is read by the transmitting node. If a message is not acknowledged (perhaps because the receiver has
failed), an ACK error is flagged.
[...]

Adding yet another level of error-detection doesn't make much sense.

 

It is the customer requirement and mainly safety related automotive application. So, I have to do it.

 

It is the customer requirement and mainly safety related automotive application. So, I have to do it.
[...]
So when i am sending data i want to use the checksum calculation and the receiving end can make sure that the data is correct.

That's it, append checksum to data sent and then verify on the receiving end.

 

I have this requirement, 4 bit counter used in checksum calculation. X=Y (modulo 16). I don't have further details on this. Anything i can make out of it or what should i do? Do i need to get further details from the customer?

 

I have this requirement, 4 bit counter used in checksum calculation. X=Y (modulo 16). I don't have further details on this. Anything i can make out of it or what should i do? Do i need to get further details from the customer?

Anything you can make out what? I don't understand your question.

Do keep in mind that a 4-bit CRC is only going to be barely sufficient for up to about 16 bits (2 bytes) of data. That's a best-case scenario, assuming you've selected the right generator (safest bet: go with a primitive polynomial). Anything above that length of input is basically going to render the CRC pointless...

EDIT: 16 bits, not bytes

 

This sounds more like a training exercise. I hope I never buy a car from your "customer's" company who does not give a more detailed specification and sub contracts to a company that does not have expertise in the field.

Les.

 

i did not say it is 4 bit CRC. In 8 bytes of CAN data 1 byte (4 bits) will be a kind of counter increments from 1 to 16. One more byte will be the actual checksum which is calculated from this counter.

 

i did not say it is 4 bit CRC. In 8 bytes of CAN data 1 byte (4 bits) will be a kind of counter increments from 1 to 16. One more byte will be the actual checksum which is calculated from this counter.

Okay, so you're saying that you intend to apply an 8-bit CRC to 4 individual bits within a 64-bit stream of data. Correct?

 

This is the conclusion i arrived at. I have a signal "S" (10 bit information) which i need to protect it. To protect it I need to use a 4 bit counter and calculate the 8 bit checksum. The way the 4 bit counter used as i mentioned earlier (4 bit counter used in checksum calculation. X=Y (modulo 16)). I am not sure if I still miss some information or it is enough to calculate the checksum.

 

This is the conclusion i arrived at. I have a signal "S" (10 bit information) which i need to protect it. To protect it I need to use a 4 bit counter and calculate the 8 bit checksum. The way the 4 bit counter used as i mentioned earlier (4 bit counter used in checksum calculation. X=Y (modulo 16)). I am not sure if I still miss some information or it is enough to calculate the checksum.

I still don't get it. What's the point of the 4-bit counter?

 

My guess is something like this
Tx Message1: Signal_Value1, 1, checksum1
Tx Message2: Signal_Value2,2, Checksum2
...
Tx Message16: Signal_Value16,16,Checksum16
Tx Message17: Signal_Value17,1,Checksum17
and so on..

 

My guess is something like this
Tx Message1: Signal_Value1, 1, checksum1
Tx Message2: Signal_Value2,2, Checksum2
...
Tx Message16: Signal_Value16,16,Checksum16
Tx Message17: Signal_Value17,1,Checksum17
and so on..

So something along the lines of a frame number. But do you mean to apply the CRC to the counter, the payload, or both?

 

I think i need to apply CRC to the payload but using the counter i suppose.

 

I think i need to apply CRC to the payload but using the counter i suppose.

Right well that just sounds nonsensical, frankly. I would say get a clarification on the specs, figure out your CRC routine, and then proceed from there. Because this guessing game isn't going to get you any closer to your goal.

 

Ok i don't know, i guessed.

 

Ok i don't know, i guessed.

Fair enough, at least you admit it...

 

I have seen this line in the document. "4 bit counter used in checksum calculation". I don't think the document is mistake. In any case i will try to get some help from them.