26

My CAN bus is running at 125 kbit/s and is using extended frame format exclusively. I would like to know what's the maximum rate of CAN frame I can send out. Suppose the data length is always eight bytes.

According to this Wikipedia page, each frame has a maximum frame length of (1+11+1+1+18+1+2+4+64+15+1+1+1+7) = 128 bits:

Enter image description here

Taking into account of a minimum three bits interframe spacing, the maximum packet rate under 125 kbit/s should be: 125000 / ( 128 + 3) = 954 frames per second.

But in my test, I couldn't get that high. The maximum frame rate I can achieve (with all eight bytes data) is around 850 frames per second.

What's wrong here - my calculation, or my test method?

Peter Mortensen
  • 1,676
  • 3
  • 17
  • 23
Penghe Geng
  • 597
  • 1
  • 5
  • 14
  • 1
    Look at it with a scope and see what you are actually getting. Perhaps your hardware isn't ready to transmit a new frame after immediately after having sent one. Also, are you taking the ACK time into account? Your unlabeled sum of bits is not helpful in telling us what exactly you are counting. – Olin Lathrop Jul 15 '14 at 16:34
  • In practice, it's hard to get 100% bus utilisation for any extended time over a CAN bus, due to the need for ACK times and interframe spacing. Your CAN controller may not be able to support 100% bus utilisation for any extended length of time. – Tristan Jul 15 '14 at 16:49
  • 3
    Depending on exactly what data you're sending, bit stuffing can increase your frame size by up to 10%. – WhatRoughBeast Jul 15 '14 at 17:06
  • @WhatRoughBeast Do you mean the interframe spacing changes depending on the package content? Do you have a link for some detail? – Penghe Geng Jul 15 '14 at 23:10
  • @OlinLathrop \@TristanSerifert - Since ACK is just a bit field of a CAN frame field, how can it affect the transmission time? – Penghe Geng Jul 15 '14 at 23:12
  • 1
    @xiaobai - No, the length of the data field changes. As for a link, you already provided it. Read the entire page. If your tests are sending all zeroes or all ones, that would explain a lot. – WhatRoughBeast Jul 16 '14 at 11:23
  • 2
    ACK can effect the transmission time if you're not accounting for it. Again, your unlabeled mess of summed numbers doesn't tell us what you are really adding up, and therefore what you might be missing. – Olin Lathrop Jul 16 '14 at 11:56
  • @What: Good point. You should make that a answer, perhaps with some background on bit stuffing. It seems the OP doesn't even know it exists, and I admit I had forgotten about it. – Olin Lathrop Jul 16 '14 at 11:56
  • @WhatRoughBeast It is my understanding that if a run of four consecutive bits of the same value is sent then an extra bit of opposite polarity is added to create an edge that the controllers can use for bit timing. Does that bit stuffing apply only to the data, or to the whole frame? You say 10%, but if stuffing applies to the whole frame then wouldn't the increase be up to 20% (since up to 1 in 5 bits can be stuffed). Although I would expect the average to be much less. – user4574 Apr 30 '20 at 15:04
  • @user4574 - For CAN, it's 5 bits, not 4. And it does apply to all bits. So, in principle you could get nearly a 20% increase in packet size. And it's not entirely random, either, since you can choose your ID patterns to avoid the problem, and that can prevent stuffing over a 31-bit section. – WhatRoughBeast Apr 30 '20 at 15:24

4 Answers4

29

Per Olin Lathrop's suggestion, I'll expand on bit-stuffing.

CAN uses NRZ coding, and is therefor not happy with long runs of ones or zeroes (It loses track of where the clock edges ought to be). It solves this potential problem by bit-stuffing. When transmitting, if it encounters a run of 5 successive ones or zeros it inserts a bit of the other polarity, and when receiving, if it encounters 5 successive ones or zeroes it ignores the subsequent bit (unless the bit is the same as the previous bits, in which case it issues an error flag).

If you are sending all zeroes or all ones for your test data, a string of 64 identical bits will result in the insertion of 12 stuffed bits. This will increase total frame length to 140 bits, with a best-case frame rate of 874 frames / sec. If the data bits are the same as the MSB of the CRC, you'll get another stuffed bit there, and the frame rate drops to 868 frames/ sec. If the CRC has long runs of ones or zeroes, that will reduce the frame rate even further. The same consideration applies to your identifiers.

A total of 16 stuffed bits will produce an ideal frame rate of 850.3 frames/sec, so you ought to consider it. A quick test would be to use test data with alternating bits, and see what happens to your frame rate.

WhatRoughBeast
  • 59,978
  • 2
  • 37
  • 97
  • 4
    Yes, in my original test there are indeed lots of zeros in the payload and the ID. After I make sure there are no 5 successive zeroes either in the data or the ID, now I can get **940** frames/sec, very close to the calculated limit. Thanks a lot for the great answer. – Penghe Geng Jul 17 '14 at 14:30
5

The smallest 2.0a (standard) frame you can build is 47bits ...The smallest 2.0b (extended) frame you can build is 67bits ...That INcludes 3bits of inter-frame spacing, and EXcludes bit stuffing ...In theory we can build a frame which will never stuff; In reality, bit stuffing is going to happen quite a lot!

The maximum baud for CANBus 2.0a/b is 1Mbit.
At 1Mb/S, a single (dominant/recessive) bit is 1uS long, ie. 0.000'001 S
So a 67bit frame [the smallest theoretical 2.0b frame] will take 67uS to transmit - before another (67bit) frame may be transmitted.
1'000'000 / 67 gives 14,925 complete frames (+ 25bits of the next frame)

As you are running at 1/8th of that speed, you can get at most 1/8th of the packets
14'925 / 8 = 1'865 frames/Second @125Kb

By the time you are using all 64bits (8bytes) of data, and ASSUMING you have not triggered bit stuffing "errors" by having strings of consecutive 1's or 0's
1'000'000 / (67 + 64) = 7'633
7'633 / 8 = 954

And that's also assuming your wiring is perfect. Is your can bus made from 120ohm UTP cable and capacitively decoupled at both ends? Or some random wire with a 120ohm resistor across one end?

Overall I would say you're doing pretty well to get 90% of theoretical maximum throughput.

BlueChip
  • 141
  • 2
  • 6
1

Olin is right on with his description of bit stuffing and how that can adversely affect theoretical CAN throughput. One other thing that can further degrade actual throughput from theoretical is latency. Even if your CAN controller is able to achieve 100% bus utilization, the host processor may not be able to handle Tx and/or Rx at that rate. This could be the result of a slow processor and/or inefficient firmware that implements the CAN stack.

Trent Weaver
  • 11
  • 1
0

Another interesting question from the perspective of a receiver would be

What is the worst case maximum frame transfer frequency?

For this case stuff bits can be likely ignored, since they make the frequency lower.

.

Looking just to standard identifier frames:

For data length 1 you would have to calculate with

55 Bits (minimum overhead + 8 data bits + 3 interframe space)

--> maximum frame frequency for 1 Mbit is about 18181.8/s (1/0.000055)

For data length 0 (can be also an information) you would have to calculate with

47 Bits (minimum overhead + 3 interframe space)

--> maximum frame frequency for 1 Mbit is about 21276.6/s (1/0.000047)

Thor-x86_128
  • 13
  • 7
grenix
  • 101
  • 3