<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Some questions about Bit Stuffing and CRC32 etc. (USBCDC)</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/25787/some-questions-about-bit-stuffing-and-crc32-etc-usbcdc</link><description> 
(Sorry for my limited English ability and limited technical
ability.) 

 
I have been requested to design an I/O-Control (Communication)
Protocol. This simple protocol is designed for a LPC23xx based
USBCDC, the USBCDC software solution is based on</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Some questions about Bit Stuffing and CRC32 etc. (USBCDC)</title><link>https://community.arm.com/thread/153597?ContentTypeID=1</link><pubDate>Wed, 07 Jul 2010 03:57:51 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:20276d22-9a48-4b39-b8af-37c3858f1122</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;You normally compute a full set of output patterns with best
possible hamming distance.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Good plan, but slightly besides the point, since that&amp;#39;s no longer
bit stuffing. That&amp;#39;s a different technique which has variuos
different names: Hamming Code or Group Code Recording, among
others.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Some questions about Bit Stuffing and CRC32 etc. (USBCDC)</title><link>https://community.arm.com/thread/152919?ContentTypeID=1</link><pubDate>Wed, 07 Jul 2010 03:34:36 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a449da3b-abd6-4bf0-b615-a6d740dcfe15</guid><dc:creator>edPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Yes, of course.&lt;/p&gt;

&lt;p&gt;
Having RLL-encoded data you are only safe when your bit errors are
covered by the hamming distance of the patterns used in the stuffing.
As soon as a pattern gets more damaged, you lose synchronization.
Which may either result in incorrect decoding of following patterns
or in the receiver seeing an invalid pattern forcing it to break
reception until it sees a synchronization.&lt;/p&gt;

&lt;p&gt;
But you normally avoids stuffing schemes where you after
four-in-a-row force an extra reversed bit. It is way too fragile even
if it is compact, since there is no hamming distance. And it can be
problematic with encodings where fixed-length data can encode into
random-length output.&lt;/p&gt;

&lt;p&gt;
You normally compute a full set of output patterns with best
possible hamming distance. You may for example split the input data
into 5-bit blocks and replace with 8-bit blocks. Depending on the
size of the input and output code blocks, you can have output code
blocks with different hamming distance, allowing one or more bits in
each block be inverted while still being able to correctly decode the
data. And if a scheme with fixed size of input and output blocks is
used, bit errors may not change the length of the stream. This also
allows two-dimensional parity information to be used to greatly
improve the error-correcting abilities.&lt;/p&gt;

&lt;p&gt;
But at the very minimum, somethink like the 4B/5B encoding should
be used, where each 4-bit group is converted to a 5-bit group with
good self-clocking properties and making sure you have a fixed length
making sure that bit errors will not produce a a random sequence of
decoded bit errors. And the 4B/5B encoding have patterns available
for inlining commands in the data stream.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Some questions about Bit Stuffing and CRC32 etc. (USBCDC)</title><link>https://community.arm.com/thread/152147?ContentTypeID=1</link><pubDate>Wed, 07 Jul 2010 02:58:04 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:5f177ee4-3a5a-4816-8d7e-57f2f296357c</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;where the CRC can detect 5 bit errors but it can be enough with
2 bit errors to lose the synchronization.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
It&amp;#39;s a little worse than that. A full-on violation of the
bit-stuffing rules would be detectable by the receiver, at which
point it knows that the data are compromised without even looking at
the CRC.&lt;/p&gt;

&lt;p&gt;
The real problem is that you can have pairs of bit-flips that
transfrom one correctly bit-stuffed frame into another correctly
bit-stuffed frame. Basically, in a 4-&amp;gt;5 bit stuffing scheme:&lt;/p&gt;

&lt;pre&gt;
000010101010101110001 -unstuff-&amp;gt; 0000.0101.0101.0111.0001
2 bits flipped:
0&lt;b&gt;1&lt;/b&gt;001010101010111&lt;b&gt;1&lt;/b&gt;001 -unstuff-&amp;gt; 0100.1010.1010.1011.1101
&lt;/pre&gt;

&lt;p&gt;
So two flipped bits in the stuffed stream can turn into a
basically unlimited number of flipped bits in the un-stuffed stream.
And that breaks CRC&amp;#39;s Hamming distance property, because the
un-stuffed stream now has not 2, but about 10 flipped bits.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Some questions about Bit Stuffing and CRC32 etc. (USBCDC)</title><link>https://community.arm.com/thread/151378?ContentTypeID=1</link><pubDate>Wed, 07 Jul 2010 01:57:02 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:54be6acf-ec16-4d8a-aa11-7c2f913d7344</guid><dc:creator>edPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
The use of escape sequences in data messages is normally called
_byte_ stuffing as compared to the _bit stuffing in RLL-encoded data
where the data may only have a limited number of 1 or 0 in a sequence
to maintain self-clocking and where messages normally starts with
magic bit patterns (such as a long sequence of ones) that may not
happen within the data.&lt;/p&gt;

&lt;p&gt;
One thing with RLL data is that if you have a scheme where you may
not have more than 5 consecutive zeroes or ones, a single bit toggle
may extend one such sequence - possibly even merging two sequences
making 5+1+5 into 11 consecutive bits. You normally avoids code
sequences where a single bit error can result so grave errors by
defining patterns with a specific &amp;quot;resilience&amp;quot; by making sure that
there is a suitable hamming distance between the allowed
patterns.&lt;/p&gt;

&lt;p&gt;
But it doesn&amp;#39;t matter how good CRC is to detect an error in a
message, if you get more bit errors in such a pattern than it can
support. On one hand, one pattern may suddenly look like a different
pattern. This can be detected by CRC. But the bit errors can break
the self-clocking properties of the data stream in which case you
will have to wait for the next block start. Without synchronization,
you may not even be able to locate the bits that after unstuffing
should form the CRC.&lt;/p&gt;

&lt;p&gt;
So you may have a data encoding scheme where the CRC can detect 5
bit errors but it can be enough with 2 bit errors to lose the
synchronization. The damaged data is no longer self-clocking.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Some questions about Bit Stuffing and CRC32 etc. (USBCDC)</title><link>https://community.arm.com/thread/146568?ContentTypeID=1</link><pubDate>Wed, 07 Jul 2010 01:12:57 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:67d2ee3e-361f-4fe7-a3de-8bdde627fca8</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;I think/guess:&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;Tsuneo is talking about the probability distribution, one is
random bit errors, another is a paired bit error.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Actually he&amp;#39;s trying to argue against the results of that paper at
jcho.de, which concern how bit stuffing reduces error-checking
capability of a CRC. And his argument is, IMHO, wrong.&lt;/p&gt;

&lt;p&gt;
OTOH, what you&amp;#39;re doing there is &lt;b&gt;not&lt;/b&gt; actually bit stuffing.
It&amp;#39;s a plain old escape character mechanism. Bit stuffing happens on
the layer where individual bits actually get sent over the data line
of a (synchronous) serial protocol. It&amp;#39;s used to avoid extended
periods without any signal changes on the line.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Some questions about Bit Stuffing and CRC32 etc. (USBCDC)</title><link>https://community.arm.com/thread/144910?ContentTypeID=1</link><pubDate>Tue, 06 Jul 2010 18:46:47 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:fc7bc662-6085-4477-b63a-db90b1d2416a</guid><dc:creator>John Linq</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks to all.&lt;/p&gt;

&lt;p&gt;
I am trying to understand all these comments &lt;b&gt;with my very
limited ability&lt;/b&gt;. I write down my understanding here so that, it
can be verified by Experts.&lt;/p&gt;

&lt;p&gt;
I think/guess:&lt;/p&gt;

&lt;p&gt;
Tsuneo is talking about the probability distribution, one is
random bit errors, another is a paired bit error. This talking is
mainly for Figures Comparing.&lt;/p&gt;

&lt;p&gt;
Hans-Bernhard is talking about CRC Error Detection. This talking
is mainly for how Stuffing affects Error Detection.&lt;/p&gt;

&lt;p&gt;
And Per is talking about different CRC polynomials have different
behaviors.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Some questions about Bit Stuffing and CRC32 etc. (USBCDC)</title><link>https://community.arm.com/thread/142663?ContentTypeID=1</link><pubDate>Tue, 06 Jul 2010 07:04:27 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:fa346643-1114-435e-9a1a-bdbe48c33b3b</guid><dc:creator>edPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
&amp;quot;The effect of bit stuffing reduces this to two. I.e. you can now
get a false-positive check by flipping only 2 bits.&amp;quot;&lt;/p&gt;

&lt;p&gt;
That still greatly depends on if you compute crc on the stuffed or
unstuffed data.&lt;/p&gt;

&lt;p&gt;
And the next thing is that different CRC polynomials have
different behaviour. On one hand, they can handle a limited number of
random bit errors. But you can get a different performance for a
burst error compared to randomly spaced bit errors.&lt;/p&gt;

&lt;p&gt;
And having an inner CRC (message data) and an outer CRC (carrier
protocol) does greatly affect the probability of an error not being
detected. Multiple detection methods quickly increases the
probability of detecting an error - you don&amp;#39;t have just a crc16
anymore.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Some questions about Bit Stuffing and CRC32 etc. (USBCDC)</title><link>https://community.arm.com/thread/139628?ContentTypeID=1</link><pubDate>Tue, 06 Jul 2010 03:25:30 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:fa3e24fb-ffe6-4ade-b12a-50a0a0288e11</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;hamming distance of CRC. As the background, random error is
supposed.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
No. Background has nothing to do with it. Hamming distance is
about &lt;b&gt;any&lt;/b&gt; kind of error, regardless of whether it&amp;#39;s random or
not. A CRC16 guarantees that you have to flip at least 5 bits before
you can get a false-positive check result.&lt;/p&gt;

&lt;p&gt;
The effect of bit stuffing reduces this to two. I.e. you can now
get a false-positive check by flipping only 2 bits.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Some questions about Bit Stuffing and CRC32 etc. (USBCDC)</title><link>https://community.arm.com/thread/136205?ContentTypeID=1</link><pubDate>Mon, 05 Jul 2010 12:33:59 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:4b9cb986-7a9c-4077-882f-cf4dca233499</guid><dc:creator>Chinzei Tsuneo</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;a href="http://jcho.de/jc/Pubs/cia-94.pdf"&gt;jcho.de/.../cia-94.pdf&lt;/a&gt;&lt;br /&gt;

3.4 Error Transformation&lt;br /&gt;
&lt;i&gt;&amp;quot;Due to the bit stuffing effects, the error detection capabilities
of the CRC are reduced from safely detecting h - 1 = 5 bit errors to
2 errors.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
This conclusion is typical lie using figures, which cannot be
compared with each other.&lt;/p&gt;

&lt;p&gt;
&amp;quot;h - 1 = 5 bit errors&amp;quot; derives from hamming distance of CRC. As
the background, random error is supposed.&lt;/p&gt;

&lt;p&gt;
On the other hand, &amp;quot;2 errors&amp;quot; stands for ONE stuff bit deleting
error AND ONE stuff bit creating error. These deleting/creating
errors should be in a pair, because CAN (and USB also) checks byte
boundary. The probability of these deleting/creating error bits
aren&amp;#39;t random one.&lt;/p&gt;

&lt;p&gt;
As the background probability structure is different, these two
figures can&amp;#39;t be compared directly.&lt;/p&gt;

&lt;p&gt;
Tsuneo&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Some questions about Bit Stuffing and CRC32 etc. (USBCDC)</title><link>https://community.arm.com/thread/126254?ContentTypeID=1</link><pubDate>Sun, 04 Jul 2010 19:04:12 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:414fec4c-64a5-4e31-b152-de8c76cf495f</guid><dc:creator>John Linq</dc:creator><description>&lt;p&gt;&lt;p&gt;
Hi Per,&lt;/p&gt;

&lt;p&gt;
Many Thanks.&lt;/p&gt;

&lt;p&gt;
Due to my limited ability, I didn&amp;#39;t read those two articles
talking about the Stuffing affects CRC Error Detection. I just
searched/found the sentences, which I think I need. Now, with your
comments, I have more confidence with my original guess, at least, I
know my original guess is reasonable.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Some questions about Bit Stuffing and CRC32 etc. (USBCDC)</title><link>https://community.arm.com/thread/115874?ContentTypeID=1</link><pubDate>Fri, 02 Jul 2010 10:08:30 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:cb9e4575-586d-4e25-a16e-7fbad077468f</guid><dc:creator>edPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Stuffing will affect differently depending on how you stuff. And
it will also affect differently if you compute the CRC on the stuffed
or unstuffed data (but you still need to stuff the CRC itself).&lt;/p&gt;

&lt;p&gt;
In the case of USB as carrier, you will have one layer of CRC in
the USB transmissions and another layer of CRC in your protcol. I
haven&amp;#39;t really checked when CRC5 and when CRC16 is used by USB.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Some questions about Bit Stuffing and CRC32 etc. (USBCDC)</title><link>https://community.arm.com/thread/104078?ContentTypeID=1</link><pubDate>Fri, 02 Jul 2010 09:13:52 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:495d57fb-ce60-408f-a69a-301ca5501870</guid><dc:creator>John Linq</dc:creator><description>&lt;p&gt;&lt;p&gt;
It seems that there is no shortcut, so I just did a quick google
search.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&lt;br /&gt;
&lt;a href="http://jcho.de/jc/Pubs/cia-94.pdf"&gt;jcho.de/.../cia-94.pdf&lt;/a&gt;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;The effect of error multiplication due to bit stuffing has
first been stated in [4] for the HDLC protocol and&lt;br /&gt;
in [3] for CAN. Due to the bit stuffing effects, the error detection
capabilities of the CRC are reduced from&lt;br /&gt;
safely detecting h - 1 = 5 bit errors to 2 errors.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
I also found one Simplified Chinese article talking about the
Stuffing of CAN protocol affects its CRC Error Detection.&lt;/p&gt;

&lt;p&gt;
So, it is not wise to use both CRC and Stuffing at the same time?
Am I right?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Some questions about Bit Stuffing and CRC32 etc. (USBCDC)</title><link>https://community.arm.com/thread/90500?ContentTypeID=1</link><pubDate>Thu, 01 Jul 2010 19:32:50 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:14ac8767-df47-4696-85ef-ce9656b3958f</guid><dc:creator>John Linq</dc:creator><description>&lt;p&gt;&lt;p&gt;
I know that, &lt;i&gt;Considerable error checking and error handling
features have been built in to the USB to ensure that it is a
reliable method of connecting peripherals to a PC. Data integrity
should be comparable to that of an internal expansion bus.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
And I have already explained the reliability of USB to them, but
the CRC32 field is still a request I have to follow.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Some questions about Bit Stuffing and CRC32 etc. (USBCDC)</title><link>https://community.arm.com/thread/58396?ContentTypeID=1</link><pubDate>Thu, 01 Jul 2010 19:14:12 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:74f4cb2f-03b0-415c-8a51-be9d69da06a4</guid><dc:creator>John Linq</dc:creator><description>&lt;p&gt;&lt;p&gt;
I forgot.&lt;/p&gt;

&lt;p&gt;
The USB protocol is not a raw protocol, so the transmitted data
will be processed before the transmission , and it will not be the
same as the original one.&lt;/p&gt;

&lt;p&gt;
I think my question should be: will the Stuffing &lt;b&gt;(for a raw
protocol)&lt;/b&gt; break the CRC32 Error Detection? Because, the
transmitted data is stuffed, not the same as the original one.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>