Controller Area Network (CAN) is a serial network that was originally designed for the automotive industry, but has also become a popular bus in industrial automation as well as other applications. The CAN bus is primarily used in embedded systems, and as its name implies, is the network established among microcontrollers. A simplified CAN bus Each device or device group has a CAN ECU For example the block thermistor, instrument panel, foot brake and light clusters each have an ECU These ECUs all send and receive messages on the CAN bus The level of CAN ‘granularity’ will vary from manufacturer to manufacturer,.
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, each frame has a maximum frame length of (1+11+1+1+18+1+2+4+64+15+1+1+1+7) = 128 bits:Taking into account of a minimum three bits, 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?
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.
![What What](/uploads/1/2/5/6/125656997/538317388.jpg)
![Company Company](/uploads/1/2/5/6/125656997/324589987.jpg)
A quick test would be to use test data with alternating bits, and see what happens to your frame rate. 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 SSo 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 packets14'925 / 8 = 1'865 frames/Second @125KbBy 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's1'000'000 / (67 + 64) = 7'6337'633 / 8 = 954And 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.