Hi We're using the 68302 micro with DDCMP serial protocol over two wire RS485. According to the user manual, this uses CRC16-CCITT - X**16 X**12 X**5 + 1. Does anyone have any idea what the chance of getting an undetected error is with this protocol? I know all single bit errors are detected. Supposing we run a point to point connection at slightly faster than it's really capable of and we get 10% of messages with more than a single bit error. What percentage of these will go undetected by the CRC check? Suppose we run the connection at a "normal" baud rate with almost no errors. What is the likelihood of getting undetected errors now? Thanks for any help.
error detection rate with crc-16 CCITT
Started by ●March 27, 2011
Reply by ●March 27, 20112011-03-27
On Sun, 27 Mar 2011 01:58:32 -0700 (PDT), Shane williams <shane.2471958@gmail.com> wrote:>Hi > >We're using the 68302 micro with DDCMP serial protocol over two wire >RS485. According to the user manual, this uses CRC16-CCITT - X**16 >X**12 X**5 + 1. > >Does anyone have any idea what the chance of getting an undetected >error is with this protocol? I know all single bit errors are >detected. Supposing we run a point to point connection at slightly >faster than it's really capable of and we get 10% of messages with >more than a single bit error. What percentage of these will go >undetected by the CRC check? > >Suppose we run the connection at a "normal" baud rate with almost no >errors. What is the likelihood of getting undetected errors now?The Wikipedia article on the "Mathematics of CRC" is short and a good place to start. The paper it references <http://www.ece.cmu.edu/~koopman/roses/dsn04/koopman04_crc_poly_embedded.pdf> has the analysis you are looking for. Note (as mentioned in the wikipedia article) that the paper's convention for representing the polynomial differs from the usual method. -- Rich Webb Norfolk, VA
Reply by ●March 27, 20112011-03-27
In article <13c95ff0-d9ca-4f0b-92a4-d21fe6c36c55 @j35g2000prb.googlegroups.com>, shane.2471958@gmail.com says...> > Hi > > We're using the 68302 micro with DDCMP serial protocol over two wire > RS485. According to the user manual, this uses CRC16-CCITT - X**16 > X**12 X**5 + 1. > > Does anyone have any idea what the chance of getting an undetected > error is with this protocol? I know all single bit errors are > detected. Supposing we run a point to point connection at slightly > faster than it's really capable of and we get 10% of messages with > more than a single bit error. What percentage of these will go > undetected by the CRC check? > > Suppose we run the connection at a "normal" baud rate with almost no > errors. What is the likelihood of getting undetected errors now? > > Thanks for any help.The CRC-16 will be able to detect errors in 99.9984 percent of cases. This stems from the code being one value off out of 16-bits of error code count. 65535 / 65536 = 0.999984 percent See: http://automationwiki.com/index.php?title=CRC-16-CCITT for some implementation ideas. ------------- Are you getting some of the errors in your transmission path due to distortion of the RS485 waveform due to non-equal propagation delays through your logic on the "0"-->"1" transition versus the one from "1"-->"0"? Common problem with certain optocouplers. ;-) -- Michael Karas Carousel Design Solutions http://www.carousel-design.com
Reply by ●March 27, 20112011-03-27
On Mar 27, 11:53=A0pm, Michael Karas <mka...@carousel-design.com> wrote:> In article <13c95ff0-d9ca-4f0b-92a4-d21fe6c36c55 > @j35g2000prb.googlegroups.com>, shane.2471...@gmail.com says... > > > > > > > > > > > > > Hi > > > We're using the 68302 micro with DDCMP serial protocol over two wire > > RS485. =A0According to the user manual, this uses CRC16-CCITT =A0- X**1=6> > X**12 =A0X**5 + 1. > > > Does anyone have any idea what the chance of getting an undetected > > error is with this protocol? =A0I know all single bit errors are > > detected. =A0Supposing we run a point to point connection at slightly > > faster than it's really capable of and we get 10% of messages with > > more than a single bit error. =A0What percentage of these will go > > undetected by the CRC check? > > > Suppose we run the connection at a "normal" baud rate with almost no > > errors. =A0What is the likelihood of getting undetected errors now? > > > Thanks for any help. > > The CRC-16 will be able to detect errors in 99.9984 percent of cases. > This stems from the code being one value off out of 16-bits of > error code count. > > 65535 / 65536 =3D 0.999984 percent > > See:http://automationwiki.com/index.php?title=3DCRC-16-CCITT > > for some implementation ideas. > > ------------- > > Are you getting some of the errors in your transmission path > due to distortion of the RS485 waveform due to non-equal propagation > delays through your logic on the "0"-->"1" transition versus the > one from "1"-->"0"? Common problem with certain optocouplers. ;-) > > -- > > Michael Karas > Carousel Design Solutionshttp://www.carousel-design.comThanks. I'm trying to figure out whether it's possible/ viable to dynamically determine the fastest baud rate we can use by checking the error rate. The cable lengths and types of wire used when our systems are installed varies and I was hoping we could automatically work out what speed a particular connection can run at. The spec for the MOC5007 Optocoupler seems a bit vague so I was trying to find a better one.
Reply by ●March 27, 20112011-03-27
Shane williams wrote:> Thanks. I'm trying to figure out whether it's possible/ viable to > dynamically determine the fastest baud rate we can use by checking the > error rate.Yes. But: 1) It is easier, faster and more reliable to evaluate the channel by transmitting a known pseudo-random test pattern rather then the actual data. 2) If the baud rate is changed dynamically, how would the receivers know the baud rate of the transmitters? 3) Since the system is intended to be operable even at the lowest baud, why not always use the lowest baud? Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●March 27, 20112011-03-27
> I'm trying to figure out whether it's possible/ viable to > dynamically determine the fastest baud rate we can use by checking the > error rate.Packet length for a 16 bit CRCs should be limited to 4kbyte. The CRC doesn�t know at which baud rate the packets are coming. Your assumption ( which may well be true ) is that the error-pattern shifts from singlebit to bursts and more errors will go undetected. But the detected error rate would go way up too. By counting retransmissions now and later at the higher baud rate one could easily see if that has happened and switch to a 24 bit or 32 bit CRC. MfG JRD
Reply by ●March 27, 20112011-03-27
On 03/27/2011 03:53 AM, Michael Karas wrote:> In article<13c95ff0-d9ca-4f0b-92a4-d21fe6c36c55 > @j35g2000prb.googlegroups.com>, shane.2471958@gmail.com says... >> >> Hi >> >> We're using the 68302 micro with DDCMP serial protocol over two wire >> RS485. According to the user manual, this uses CRC16-CCITT - X**16 >> X**12 X**5 + 1. >> >> Does anyone have any idea what the chance of getting an undetected >> error is with this protocol? I know all single bit errors are >> detected. Supposing we run a point to point connection at slightly >> faster than it's really capable of and we get 10% of messages with >> more than a single bit error. What percentage of these will go >> undetected by the CRC check? >> >> Suppose we run the connection at a "normal" baud rate with almost no >> errors. What is the likelihood of getting undetected errors now? >> >> Thanks for any help. > > > The CRC-16 will be able to detect errors in 99.9984 percent of cases. > This stems from the code being one value off out of 16-bits of > error code count. > > 65535 / 65536 = 0.999984 percentIt isn't that simple. CRC-16 will be able to detect _all_ 1, 2 and 3 bit errors, and some 4-bit errors. How many 'cases' of four bit errors in a message depends on the message length and your error rate, so right there your fixed percentage of errors detected goes right out the window. Read the article cited by Rich Webb. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●March 27, 20112011-03-27
On 03/27/2011 04:39 AM, Shane williams wrote:> On Mar 27, 11:53 pm, Michael Karas<mka...@carousel-design.com> wrote: >> In article<13c95ff0-d9ca-4f0b-92a4-d21fe6c36c55 >> @j35g2000prb.googlegroups.com>, shane.2471...@gmail.com says... >> >> >> >> >> >> >> >> >> >> >> >>> Hi >> >>> We're using the 68302 micro with DDCMP serial protocol over two wire >>> RS485. According to the user manual, this uses CRC16-CCITT - X**16 >>> X**12 X**5 + 1. >> >>> Does anyone have any idea what the chance of getting an undetected >>> error is with this protocol? I know all single bit errors are >>> detected. Supposing we run a point to point connection at slightly >>> faster than it's really capable of and we get 10% of messages with >>> more than a single bit error. What percentage of these will go >>> undetected by the CRC check? >> >>> Suppose we run the connection at a "normal" baud rate with almost no >>> errors. What is the likelihood of getting undetected errors now? >> >>> Thanks for any help. >> >> The CRC-16 will be able to detect errors in 99.9984 percent of cases. >> This stems from the code being one value off out of 16-bits of >> error code count. >> >> 65535 / 65536 = 0.999984 percent >> >> See:http://automationwiki.com/index.php?title=CRC-16-CCITT >> >> for some implementation ideas. >> >> ------------- >> >> Are you getting some of the errors in your transmission path >> due to distortion of the RS485 waveform due to non-equal propagation >> delays through your logic on the "0"-->"1" transition versus the >> one from "1"-->"0"? Common problem with certain optocouplers. ;-) >> >> -- >> >> Michael Karas >> Carousel Design Solutionshttp://www.carousel-design.com > > Thanks. I'm trying to figure out whether it's possible/ viable to > dynamically determine the fastest baud rate we can use by checking the > error rate. The cable lengths and types of wire used when our systems > are installed varies and I was hoping we could automatically work out > what speed a particular connection can run at. The spec for the > MOC5007 Optocoupler seems a bit vague so I was trying to find a better > one.If you creep up on things, looking for one or two bit errors per packet and backing off, then you should do OK. I'm with Vladimir, however, that if you can you should consider just sending pseudo-random sequences. Error counting with those is easy-peasy, and if you know it's coming down the pike you don't have to worry about corrupting data that you depend on. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●March 27, 20112011-03-27
On 03/27/2011 07:21 AM, Vladimir Vassilevsky wrote:> > > Shane williams wrote: > > >> Thanks. I'm trying to figure out whether it's possible/ viable to >> dynamically determine the fastest baud rate we can use by checking the >> error rate. > > Yes. But: > > 1) It is easier, faster and more reliable to evaluate the channel by > transmitting a known pseudo-random test pattern rather then the actual > data.I've done this -- and it is.> 2) If the baud rate is changed dynamically, how would the receivers know > the baud rate of the transmitters?There's ways. Any good embedded programmer should be able to figure out half a dozen before they even put pen to napkin.> 3) Since the system is intended to be operable even at the lowest baud, > why not always use the lowest baud?If it's like ones that I've worked with, the data over the link is a combination of high-priority "gotta haves" like operational data, and lower-priority "dang this would be nice" things like diagnostics, faster status updates, and that sort of thing. So the advantages of going up in speed are obvious. For that matter, there may be advantages to being able to tell the a maintenance guy what not-quite-fast-enough speed can be achieved, so he can make an informed choice about what faults to look for. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●March 27, 20112011-03-27
Tim Wescott wrote:> It isn't that simple. CRC-16 will be able to detect _all_ 1, 2 and 3 bit > errors, and some 4-bit errors.I've often wondered about that statement. Suppose you get a 1 bit error in the message and an error in the crc remainder that results in a "good" message? Is there an implicit guarantee in the algorithm that it will take more than 3 bits to "fix" the remainder. My apologies if this is covered in the Webb article, running late today and don't have time to read it.
