Application software protection mechanism

xox

Joined Sep 8, 2017
936
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.
The phrase "used in" could mean a lot of things. So yes, a detailed description of the protocol layer being implemented is what you really need at this point.
 

Thread Starter

electronicsLearner77

Joined May 26, 2012
127
Ok whether it is the correct or wrong, can i do something like this. Does it have any meaning
Let the payload is 26, current counter is 8, modulo 16 23%8 = 7, so checksum is 7. So the message is
Message 26, 8, 7. Is it possible something like this? As per the document i have to use modulo(16). And sorry for the trouble.
 

xox

Joined Sep 8, 2017
936
Ok whether it is the correct or wrong, can i do something like this. Does it have any meaning
Let the payload is 26, current counter is 8, modulo 16 23%8 = 7, so checksum is 7. So the message is
Message 26, 8, 7. Is it possible something like this? As per the document i have to use modulo(16). And sorry for the trouble.
You do realize that a CRC is a form of division over a second-order Galois field polynomial, right?
 

WBahn

Joined Mar 31, 2012
32,852
Is it just me, or does it seem like the requirements and constraints keep getting dribbled out a little at a time?

Leaving that aside, what kind of errors are you trying to protect against? Random errors? Burst errors? Malicious jamming? If the "customer" isn't satisfied with the build in error detection/correction that is part of the protocol, there must be some reason why they are concerned that the type of errors they might get won't get caught by the built in protocols. So either they believe that a particular type of error is more likely than normal, or they want you to add protection for some of the errors that would be missed by the build in protocols (all error detection schemes will miss some types of errors).
 
Top