Data Length vs CRC Length

Go To Last Post
25 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi

 

I think for every byte of data, we need one byte CRC

 

then if we have 64 byte data - we must have 64 byte CRC !!!   That doesn't sound logicallaugh

 

// this is the format of the CRC ( n < x )

data           : (x) bit

polynomial : (n) bit

CRC           : (n-1) bit

 

example ( decimal format, data 2byte ) : 

data           : 12345   ( binary : 11 0000 0011 1001 )

polynomial : 305       ( binary :           1 0011 0001 )

CRC           : 255       ( binary :             1111 1111 )

 

but my problem is that > now for data=12345, crc=255 but for crc with this value ( 255 ), we have other data ( 2byte ) with this crc!!! for example : data=255 and ...

 

when we have several data with similar crc, ITS NOT GOOD indecision

 

What can we do now? 

 

my answer is that, for set eror ( The probability of crc for several data (2byte ) being equal ) to zero, we must have CRC with number bits equal to Data

 

even for test, i wrote an softwer with c# ( for calculate all crc for data between 0 to 2 byte/65535 ) laugh

 

where is my problem? crc is not good idea or i mistake? I got a little confused cryingsad

 

 

 

 

 

http://www.ghsi.de/pages/subpage...

 

 

 

This topic has a solution.

mahdi damirchilu, my blog : dmf313

Last Edited: Fri. Dec 13, 2019 - 12:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

No, you take the data, byte by byte. There is no correlation between the data size and the CRC length. CRC length has more to do with  the odds of missing an error or getting a false error.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CRCs are generally always 1, 2 or 4 bytes. That can even be true if it's checksumming GBs of data.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

No, you take the data, byte by byte. There is no correlation between the data size and the CRC length. CRC length has more to do with  the odds of missing an error or getting a false error.

 

Jim

I'm sorry but I didn't understand.

 

what is the purpose of CRC? ---> receiver be able to detect the data is correct or not? --> yea?

mahdi damirchilu, my blog : dmf313

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
CRCs are generally always 1, 2 or 4 bytes. That can even be true if it's checksumming GBs of data.

can u write an example for 'FRAME' ? blush

 

You and Mr. Jim say :

1 Frame = 1byte Data + 1 byte CRC ---> then CRC length is not important so mutch ---> yea? enlightened

mahdi damirchilu, my blog : dmf313

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As Jim mentions, the value CRC is based on statistics. The larger the crc, the less likely you will have different sequences generating the same CRC. As well, CRCs are normally applied to serial data - the expectation is that you get bit errors and for a single bit error, the CRC generates a different number. So, it is not foolproof. Where you do have different sequences generate the same CRC value, you'll find the sequences are very different. Apply statistics to the likelihood of the expected error source to cause such a change. 

 

CRCs are popular because they are easy to generate/check in hardware - they are a shift register with some xor gates.

 

Don't choose a random CRC polynomial - some work better than others. Best to choose a popular polynomial as it has been proven to work.

 

If you want something that is unlikely to have a collision, look at using cryptographic hashes.  Unfortunately, these are much more processor intensive unless your processor chip has special hardware to help.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Don't choose a random CRC polynomial - some work better than others
Indeed.

 

Kartman wrote:
Best to choose a popular polynomial as it has been proven to work.
You'd be surprised.

 

md3848 wrote:
where is my problem? crc is not good idea or i mistake? I got a little confused
Volumes have been written.  Careers have been made.

 

https://en.wikipedia.org/wiki/Cyclic_redundancy_check

https://betterembsw.blogspot.com/2010/05/whats-best-crc-polynomial-to-use.html

https://betterembsw.blogspot.com/search/label/error%20detection

https://users.ece.cmu.edu/~koopman/pubs/ray06_crcalgorithms.pdf

https://www.google.com/search?q=koopman+crc

http://users.ece.cmu.edu/~koopman/crc/index.html

http://users.ece.cmu.edu/~koopman/crc/crc16.html

http://users.ece.cmu.edu/~koopman/crc/notes.html

 

https://en.wikipedia.org/wiki/Mathematics_of_cyclic_redundancy_checks

 

... to name but a tiny handful.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

While popular polynomials do work, most were choosen before the polynomial space was surveyed and don't have the best error detection performance for their application. If you have the freedom to select your polynomial, you should refer to the research that has been done (nicely summarized here).

github.com/apcountryman/build-avr-gcc: a script for building avr-gcc

github.com/apcountryman/toolchain-avr-gcc: a CMake toolchain for cross compiling for the Atmel AVR family of microcontrollers

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

As Jim mentions, the value CRC is based on statistics. The larger the crc, the less likely you will have different sequences generating the same CRC. As well, CRCs are normally applied to serial data - the expectation is that you get bit errors and for a single bit error, the CRC generates a different number. So, it is not foolproof. Where you do have different sequences generate the same CRC value, you'll find the sequences are very different. Apply statistics to the likelihood of the expected error source to cause such a change. 

 

CRCs are popular because they are easy to generate/check in hardware - they are a shift register with some xor gates.

 

Don't choose a random CRC polynomial - some work better than others. Best to choose a popular polynomial as it has been proven to work.

 

If you want something that is unlikely to have a collision, look at using cryptographic hashes.  Unfortunately, these are much more processor intensive unless your processor chip has special hardware to help.

 

i dont choose random CRC polynomial ---> i chose 1 of them and test it with diffrent data ( 0-65535 ) and see for some Data, i have similar CRC ---> then i think if we have similar CRC for some data ( A, B ), then if we send "data A", but an error occur and reciver recive "data B", now with this niceeeee CRC, reciver can detect error? yea! u think right, answer is NO indecisioncrying   --->  my problem is thiisssssssssssssss ---> when crc is so weak, for what we must use it? we have no better method?

mahdi damirchilu, my blog : dmf313

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

md3848 wrote:
i dont choose random CRC polynomial ---> i chose 1 of them and test it with diffrent data ( 0-65535 ) and see for some Data, i have similar CRC ---> then i think if we have similar CRC for some data ( A, B ), then if we send "data A", but an error occur and reciver recive "data B", now with this niceeeee CRC, reciver can detect error? yea! u think right, answer is NO indecisioncrying   --->  my problem is thiisssssssssssssss ---> when crc is so weak, for what we must use it? we have no better method?

 

I tried this:

https://crccalc.com

 

I get different results for 41 and 42 hex. So what is the issue? You say CRC is weak, but where is your evidence? 

 

Eg: CRC-8 poly

 

41 hex gives C0 result

42 hex gives C9 result

 

 

As well, don't write strange English when it is not your native language - it only makes it harder for us to understand. Keep your language simple and state facts, this will allow us to help you better.

 

 

Using the online calculator,

 

The sequence 3031 hex gives a crc of CD hex using the maxim poly of 31 hex. I can only assume you are calculating the CRC incorrectly.

 

Since you are using the Maxim polynomial, this suggests you are using 1wire devices. If so, tell us first, don't let us guess.

Last Edited: Thu. Dec 12, 2019 - 11:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

apcountryman wrote:

While popular polynomials do work, most were choosen before the polynomial space was surveyed and don't have the best error detection performance for their application. If you have the freedom to select your polynomial, you should refer to the research that has been done (nicely summarized here).

 

I think, the polynomial itself doesn't matter, the number of bits polynomial are important for decrease the number of duplicate CRCs. ( I don't know, but I think I'm right, maybe ... )

 

i see that link, what is " HD " ? ( Max lengthat HD /Polynomial ... )

mahdi damirchilu, my blog : dmf313

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

HD is 'hamming distance'. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

md3848 wrote:
i dont choose random CRC polynomial ---> i chose 1 of them and test it with diffrent data ( 0-65535 ) and see for some Data, i have similar CRC ---> then i think if we have similar CRC for some data ( A, B ), then if we send "data A", but an error occur and reciver recive "data B", now with this niceeeee CRC, reciver can detect error? yea! u think right, answer is NO indecisioncrying   --->  my problem is thiisssssssssssssss ---> when crc is so weak, for what we must use it? we have no better method?

 

I tried this:

https://crccalc.com

 

I get different results for 41 and 42 hex. So what is the issue? You say CRC is weak, but where is your evidence? 

 

Eg: CRC-8 poly

 

41 hex gives C0 result

42 hex gives C9 result

 

 

As well, don't write strange English when it is not your native language - it only makes it harder for us to understand. Keep your language simple and state facts, this will allow us to help you better.

 

u use  polynomial FOR 1 byte DATA or several byte DATA ?

 

in Frame ( data + crc ), we send 1_byte_data with 1_byte_CRC or several_BYTE_data with 1_byte_CRC?

mahdi damirchilu, my blog : dmf313

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

u = You. You can type a couple extra letters to make it easier for us to read.

 

Give us an example of the problem you are facing. I gave you examples that you can try. Do they not work for you?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

I tried this:

https://crccalc.com

 

I get different results for 41 and 42 hex. So what is the issue? You say CRC is weak, but where is your evidence? 

 

Eg: CRC-8 poly

 

41 hex gives C0 result

42 hex gives C9 result

 

for " CRC-8 " in that link, for "Data = 41 hex" and "poly = 0x07", how "result = 0xC0"  ??? Can you explain the calculation procedure?

i use this method : data / poly = result ( we use XOR )

mahdi damirchilu, my blog : dmf313

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

THAT is NOT crc! Look it up instead of pretending that you are doing the right thing.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

md3848 wrote:
when crc is so weak, for what we must use it? we have no better method?
You haven't done the reading, then?

 

md3848 wrote:
I think, the polynomial itself doesn't matter
Nope.  Definitely haven't done the reading.

 

CRC is not perfect.  No error detection method is.  CRC is, however, very good, and very efficient.  It excels at detecting common types of errors in many situations.  In particular, it can be very good at detecting burst errors.

 

You cannot select a random polynomial (even a 'good' one) without first determining what your needs are.  What is the expected BER (bit error rate) of your application?  Is it subject to burst errors (such as for data transmission), or just random bit errors?

 

If you expect 100% error detection from any method, you will be forever disappointed.

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Fri. Dec 13, 2019 - 12:35 AM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
//
// Compute a Dallas Semiconductor 8 bit CRC directly.
// this is much slower, but much smaller, than the lookup table.
//
uint8_t crc8(const uint8_t *addr, uint8_t len)
{
	uint8_t crc = 0;

	while (len--) {
		uint8_t inbyte = *addr++;
		for (uint8_t i = 8; i; i--) {
			uint8_t mix = (crc ^ inbyte) & 0x01;
			crc >>= 1;
			if (mix) crc ^= 0x8C;
			inbyte >>= 1;
		}
	}
	return crc;
}

source: https://github.com/adafruit/MAX3...

 

Just doing an xor is a checksum, not a CRC. CRCs are bit orientated, so you need to shift then xor for each bit.

 

You still haven't told us precisely what you're trying to achieve - all we've got so far is obscure references to CRC and little evidence. Tell what what you want to achieve and what you've done so far - then we can move forward. At the moment we're going around in circles because you aren't asking a clear question.

Last Edited: Fri. Dec 13, 2019 - 12:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i use this method for calculate crc, its not correct? ops, then i must go and read more about correct method calculate crc...

mahdi damirchilu, my blog : dmf313

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why are you making this so hard? Why do you post a random app note page with no reference?

 

Just show us your code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That hides the way that CRC is normally done. Serially, bit by bit.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

Just doing an xor is a checksum, not a CRC. CRCs are bit orientated, so you need to shift then xor for each bit.

 

surprise ops, tyyyyyyyyyyy ( sorry, thank YOU friends laughyes ) - i think u say my main problem.

mahdi damirchilu, my blog : dmf313

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Next time you have a question - rather than try to tell us CRCs don't work, tell us 

1. what you want to achieve

2. what you've tried

3. the results you got

4. the results you expect

 

If you had done this, your problem would've been solved in one post rather than 22

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi again, 1 question, this code for calculate crc is correct or not? ( C# code )

public byte Compute_CRC8_Simple(byte[] bytes, byte polynomial)
{
	byte crc = 0; // start with 0 so first byte can be 'xored' in

	foreach (byte currByte in bytes)
	{
		crc ^= currByte; // XOR-in the next input byte

		for (int i = 0; i < 8; i++)
		{
			if ((crc & 0x80) == 0) // if last bit = 0
			{
				crc <<= 1;
			}
			else
			{
				crc = (byte)((crc << 1) ^ polynomial);
			}
		}
	}

	return crc;
}

 

 

 

And is this image below, the correct crc calculation method?,        image below and top code, is equal, yea?

 

mahdi damirchilu, my blog : dmf313

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some example algorithms here...

 

https://www.nongnu.org/avr-libc/...