2
\$\begingroup\$

Ok, it may be just peanuts, but here the author says that the max. length (i.e. max. bit stuffing) of the flexible data rate part of a 64 Byte payload frame is 673 bit (Figure 6).
That part consists of:

  • ESI (1 bit)
  • DLC (4)
  • Data field (64 * 8 + x stuff)
  • CRC (21 + 6 stuff )
  • CRC Delimiter (1)

Now, 673 is the sum of the above plus 128 stuff bits. However that means that he considered a stuff bit after four consecutive bits of the same level, like it is done for the CRC part.

But in the Data Field a stuff bit has to be inserted after five consecutive bits, hasn't it? Therefore, the max. length of the Data field is 512 + 512/5 = 615 bit, what gives a maximum of 648 instead of 673 bit.
Am I correct?

| improve this question | |
\$\endgroup\$
  • \$\begingroup\$ Just a guess, but is not bit stuffing to maintain a certain level of transitions only at the physical layer. That bit stuffing is removed when the physical layer is translated into the "data" layer. So, other than jitter, bit stuffing may not change the "data" layer one way or another. \$\endgroup\$ – st2000 Feb 6 '17 at 15:59
  • \$\begingroup\$ Almost certainly. The source of confusion on the part of the writer probably originates with the new rule that bit stuffing in the CRC occurs after 4 bits, not 5. \$\endgroup\$ – WhatRoughBeast Feb 6 '17 at 16:02
  • \$\begingroup\$ @st2000: Sure, but the stuffed bits also consume bandwidth ;-) \$\endgroup\$ – mic Feb 6 '17 at 16:03
  • \$\begingroup\$ While the stuffed bits consume bandwidth, they also increase reliability. The original usage (manufacturing control) didn't need much bandwidth, and CAN systems are noted for reliable data transfer. At the expense of bandwidth, of course. \$\endgroup\$ – WhatRoughBeast Feb 6 '17 at 18:30
1
\$\begingroup\$

The author is correct. You must take into account the presence of previous stuff bits when generating subsequent ones. For example, consider the sequence below:

Input:   00000   1111   0000   1111...
Stuffed: 00000(1)1111(0)0000(1)1111(0)...

The first stuff bit combined with the four '1's that follow requires the insertion of a '0' stuff bit after only four data bits. If this is not done then it would be possible to have a sequence of six bits of the same level in the output stream. This would defeat the purpose of CAN bitstuffing which is to provide a synchronisation edge at a maximum of five bit intervals. In other words, if the receiver must be designed to handle an interval of six bit times in some situations then they are wasting bandwidth using a five bit rule most of the time.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Of course...! Thanks for your enlightening example! :-) But: When I continue that pattern up to data bit 512, I have "only" 127 stuff bits, not 128 ;-) \$\endgroup\$ – mic Feb 20 '18 at 12:45
  • \$\begingroup\$ I don't have time right now to think it out fully, but I believe the last bit of the DLC field can force a stuff four bits into the data field. Then it would be possible to have 128 stuff bits within the data field. \$\endgroup\$ – Jon Feb 20 '18 at 13:37
  • \$\begingroup\$ FYI, the reason CAN FD has a more complicated bit stuffing scheme than classic CAN is due to an oversight in the design of the original CAN protocol. Basically the bit stuffing allows single bit errors to turn into multi-bit error runs, and this severely degrades the protection offered by the CRC. See users.ece.cmu.edu/~koopman/thesis/etran.pdf if you are interested in such things. \$\endgroup\$ – Jon Feb 20 '18 at 13:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.