Types of CAN
Low Speed CAN
This is called low speed because its baud rate is limited to 125kbps. It has a maximum of 8-byte data payload. Low speed CAN is also called as a fault tolerant CAN because if one of the wires in the bus is shorted or non-operational, the system can switch to a single-wire transmission ensuring that the system operation will continue. It is used in application that does not require speed but prefer a more fault tolerant one. Such application includes non-critical vehicle functions like interior lighting, door locks and power windows.
High Speed CAN
High speed CAN is also called a classical CAN. A high-speed CAN has a baud rate of up to 1Mbps. It has a maximum of 8-byte data payload. It is the widely used CAN in the industry. Common applications included safety systems and time critical operations or anything that need rapid and accurate response such as electronic braking, engine monitoring and management, transmission monitoring and control and line or process automations.
CAN FD
CAN FD is an extension of a classical CAN and a backward compatible to it. FD stands for flexible data-rate. The maximum baud rate of this version can reach is 8Mbps. CAN FD can use either 11-bit or 29-bit arbitration format. The 11-bit format is called as the FD base frame format. It can support up to 64 bytes of data payload. For simple and limited number of nodes, up to 2048 IDs only (2^11), CAN FD can opt to stay with 11-bit arbitration. On the other hand, if the expected number of nodes exceeds 2048, it will switch to 29-bit arbitration which can support up to 536,870,912 IDs (2^29).
It is used autonomous driving systems and high-resolution infotainment system.
CAN XL
This version of CAN offers a baud rate of up to 20MBps. It has a maximum data payload of 2048 bytes.
CAN Types Comparison Table
Operational Distance of a CAN Bus
The distance a CAN communication can go is inversely proportional to its baud rate. This means, the higher the baud rate, the shorter its operational distance. Below table summarizes common baud rates and its operational distance recommended.
Dominant and Recessive Bits, Common Mode and Differential Mode Voltages
In a CAN communication, a dominant bit is logic 0 (low) while a recessive bit is logic 1 (high). A dominant state happens when the CAN high electrical signal is around 3.5V while the CAN low is around 1.5V. This will result to a differential voltage of around 2V. On the other hand, a recessive state happens when the electrical signals for both CAN high and CAN low are around 2.5V. This results to a differential voltage of 0V. A dominant bit is an overpowering signal on the bus. If one node transmits a dominant state, it will override the recessive state transmitted by the other nodes once they coincidentally transmit at the same time.
What is a CAN Frame?
CAN messages are called frames. A frame is a complete set of message including overheads and data payload. There are 4 primary frames: Data (sends data), Remote (request data), Error (error signals) and Overload (related to delays).
CAN Frame Formats
There are two types of CAN frame formats. First is a standard frame which is under CAN2.0A and the second one is an extended frame that is under CAN2.0B.
A standard frame uses an 11-bit identifier while an extended frame uses a 29-bit identifier. The 11-bit identifier will support up to 2048 (2^11) unique IDs. On the other hand, 29-bit identifier can support up to 536,870,912 unique IDs. These 11-bit and 29-bit identifier versions are referred to the data link layer of the CAN communication. The types of CAN such as slow speed, high speed, CAN FD and CAN XL are referring to a physical layer. All these types may either CAN2.0A and CAN2.0B.
Standard CAN Frame Structure (CAN2.0A)
Extended CAN Frame Structure (CAN2.0B)
CAN Baud Rate versus Bandwidth
Baud rate and bandwidth are both measured in bits per second. However, baud rate is counting all the 1’s and 0’s transmitted in the bus which includes the start of frame arbitration field, control field, data field, CRC and so on. On the other hand, a bandwidth is only counting the data payload. Bandwidth is always smaller than baud rate. To make this definition clear, consider an average 111 bits standard CAN frame. The data payload is only 64 bits (8 bytes). If the baud rate used is 500kbps, the resulting bandwidth is only 64/111 x 500kbps = 288kbps.
CAN ID and Arbitration
CAN ID is serving as the name of the message. There are two formats for CAN ID; 11-bit and 29-bit. The 11-bit is called the standard ID while the 29-bit is called the extended ID.
An 11-bit CAN provides 2048 unique message names. On the other hand, a 29-bit ID can provide 536,870,912 unique message names. If an application involves lot of messages that the 11-bit identifier is not enough, then the best choice is to use the 29-bit identifier.
CAN is a multi-master communication. It means that any nodes in the bus can initiate data transfer anytime as long as the bus is free (no node is currently transmitting message). With this characteristic, there is a chance that nodes will send message at the same time. Since CAN bus can only accommodate a single node to use the bus at a time, there is a so-called arbitration. Node refers to each device that connects to a CAN bus.
During the arbitration, only the most priority message will use the bus first. How this achieved? This is achieved through the CAN ID. The rule is that the lowest CAN ID will be the priority. The transmitting nodes (happen to attempt data transfer at the same time) will compare their CAN IDs bit-by-bit. When a node transmits a recessive bit (logic 1) but reads a dominant bit (logic 0) in the bus, it means that a more priority message is going to use the bus. The lower priority node or nodes will give way and switch to a listening mode.
CAN Frame Transmission Process
Wait for the Bus to be Idle
This is a must. No node shall interrupt exiting bus activity. Once the bus is free, any nodes may initiate message transfer.
Arbitration
Since CAN is a multi-master communication, any node in the bus can initiate message transmission. With this, there is a tendency that nodes will attempt to use the bus at the same time. There must be only one node to use the bus at a time. To comply this, there is an arbitration process. During the arbitration, the nodes message IDs are compared bit-by-bit. When a node sending a recessive bit and read a dominant bit in the bus, it means a more priority message is going to use the bus. The node with the less priority message will give way and switch to listening mode. The general rule is during message collision is that the message with the lowest CAN ID is the priority. There are two CAN ID formats, 11-bit (standard) and 29-bit (extended).
Sending Data Payload
Once arbitration is done, the node with the priority message will get through. It will transfer its data payload. Data payload size is can be 8 bytes for low speed and high-speed CAN, 64 bytes for CAN FD and 2,048 bytes for CAN XL.
Message Reception
CAN message is broadcasted in the bus, means there is no target recipient in the message itself. All the listening nodes will check the message ID. If it is going to match on the node’s pre-programmed or whitelist IDs (in the local acceptance filter or register), the node will read the message. Otherwise, it will ignore it.
The message reception process is:
- CAN ID Matching – each node will match the message ID to its pre-programmed IDs in the local acceptance filter or register. It will read the message once it matches. Otherwise, ignore it.
- Acknowledgement – after a successful reception of a message, the receiving node pulls the bus low (dominant state) during the ACK slot to inform the sender that the message is received with no errors
- Error Handling – if the message received has errors, the node will forcibly assert stream of dominant bits (this is an error flag) to signal all other nodes that the current message is invalid. Then the transmitting node will stop the transmission immediately.
Timing of a CAN Message Update
CAN message is important to arrive the recipient on time. But how frequency the message must be updated? This is a great question for sure. There is no fixed rule. It is up to the need and the design of the CAN bus.
The Need – if the message is containing critical information such as vehicle safety and main function (braking, motor commands, etc.), set the update rate as frequent as possible (10ms – 20ms in most cases). For non-critical messages and messages that does not change frequently, a less frequent update rate is enough.
The Design – in a CAN bus, message update rate must be thought carefully. The design must consider the frequency so that the bus is not flooded with message that results to congestion. When a bus is congested, latency will occur and messages will be delayed and even dropped often.
CAN Bus Congestion and Latency
CAN Bus Congestion
A CAN bus is congested when there is excessive data flow on it. This results to latency, delays, message dropped and frequent occurrence of error frames. Congestion simply means over loading. A Healthy CAN bus must have a utilization of less than 50%.
Utilization
This is the ratio of the total bit per second transmitted to the bus to the baud rate.
Utilization = total bits per second / baud rate x 100%
How to Avoid CAN Bus Congestion
First: to avoid congestion, select the right baud rate. Baud rate is the maximum capacity of a CAN bus. It is measured in bits per second. A higher baud rate can accommodate more messages per second. Baud rate requirement is can be estimated by adding all messages expected to flow to the bus in bits per second.
For instance, there are 10 nodes in a bus (with standard CAN frame of 111 bits). Each node is going to update 100 times in a second.
Total bits per second = 10 x 111 bits x 100 / second = 111,000 bits per second
Considering maximum utilization of 50%, the minimum CAN baud rate is:
Utilization = 0.5 = total bits per second / baud rate
Baud rate = total bits per second / 0.5 = 111,000 / 0.5 = 222,000 bits per second
Thus, a baud rate of 250 kbps is a good minimum choice.
Second: It is important to manage the bus load. For static messages, update rate is no necessary frequent. The same case for less like to change parameters. Set only more frequent update to messages that contains critical information. Flooding the bus with messages though not really necessary will make it slow.
Third: Minimizing data collision is also a key. CAN is a multi-master communication. Thus, multiple nodes may transmit at the same time. This will go to arbitration so that the most priority message will go through first. This process will introduce delay and when multiple nodes are attempting to take over the bus at the same time, it has the same effect as of a congested bus. Therefore, it is a good idea to make a schedule so that there is no collision or if cannot be avoided at least minimizing it. Setting a node message update interval will help.
CAN Bus Latency
Latency refers to the time a message travel from one node to another. Total latency is the sum of bit transmission time, delays during arbitration (queuing), processing time of the controller, hardware delays, and the propagation delays across the physical media.
- Bit transmission time – this is the physical speed the digital bits transmitted to the bus. For instance, a classical CAN (high speed CAN) operating at maximum baud rate of 1Mbps, a standard 8-byte data will be transmitted at best 110 microseconds. This is not including yet the overhead.
- Arbitration Delay – since CAN is a priority-based communication, there is only one node to use the bus at a time. During the arbitration process, the lesser priority message will need to wait, there is a queuing delay. This delay is variable.
- Transmitter and Receiver processing delays – digital signals are converted to bus voltage and converted back to digital signals. This delay is could be few microseconds.
- Hardware delay – chips and circuits have inherent execution delay, for instance a newer CAN chips operating at 1Mbps will have a delay within 5-10 microseconds. Microcontrollers, isolation devices and logic gates will have delay too. Capacitances in the hardware will also increase the delay.
- Propagation delay – this dependent to the physical medium length, an estimation of 5 nanoseconds/meter. If the bus is not correctly terminated at both ends, reflection will occur and this will cause excessive delay.
How to Reduce CAN Bus Latency
- Increase baud rate – latency is the total delay incurred from the transmitter to the receiver. By using higher baud rate, more messages the bus can accommodate. Congestion related delays are out of the equation already.
- Optimize priority, avoid collision, interval and periodic update – non-critical or less likely to change message must be assigned with higher IDs to minimize if not totally avoid collision. Establish a message update interval or define a periodic update instead of letting an event to trigger to avoid message spikes. Incorporate Software Level Rate Monotonic Scheduling (RMS) wherein each node’s broadcast interval is offset, avoiding collision. Consider a Level Time Triggered CAN (TTCAN) which creates repetitive cycle of times slots and each node must broadcast only into an assign slot, eliminating arbitration.
- Use CAN FD – CAN FD has flexible data rate. During arbitration, it can support up to 1Mbps while it switches to up 8Mbps during data phase. The higher baud rate is solving congestion and the higher data payload of up to 64 bytes will reduce frame transmission time.
- Select fast hardware – Select fast microcontroller, CAN chips, isolation ICs and logic gates. Avoid introducing RC in the bus that may result to a time constant.
- Optimize the code – structure the code to avoid unnecessary processing or looping, make it straight forward as possible
- Shorten propagation delay – propagation delay is cannot be eliminated. But it can be shortened. Use the right medium, perform wire twisting or a shielded twisted pair. Ensure there is termination and the termination resistors are in the right spot. Route the CANH and CANL away from electromagnetically noisy devices, modules or harness to avoid signal corruption.
CAN Overheads
In every data message frame, it is not all of it is data. The data payload is only in the data field. For a standard data frame (most of the times 111 bits or little more depends on bit stuffing), there is only 8 bytes (64 bits) of data in the data field. The rests of the bits are called overheads.
CAN message overheads include:
- Start and end or frames
- Arbitration field
- Control field
- CRC field
- ACK field
- Bit stuffing and interframe spacing
CAN Errors
There are variety of CAN errors. These reason of these errors are combined hardware and software. However, once the software is mature already, it is less likely for it cause error.
Common errors are:
- Bit Error – when a node transmits a message in the bus, it will also monitor it. When it reads a different bit in the bus from what it transmitted (transmits recessive bit but detects dominant bit), this will trigger a bit error. The probable cause of this is a noisy CAN lines. Once the message flow in the transmission line, it will be converted to an electrical signal. This electrical signal is prone to corruption due to EMI. Another possible cause is reflection (standing waves) due to no termination or improper termination.
Fixes worth to try – ensure frame structure is correct (software), ensure to put termination (an effective termination must read 60 ohms across CANH and CANL), route the CAN wires away from electrically noisy devices and wires (to avoid EMI) and ensure to use the right wire (twisted pair or a shielded twisted pair)
- Acknowledgement Error – a node that transmit a message is expecting an acknowledgement from another node. If this is not happening, an acknowledgement error will pop-up. The usual reason of this error is a defective recipient or unpowered one or there is a connection issue.
Fixes worth to try – check for unpowered nodes or defective nodes and check connection going to each node
- CRC Error – CAN communication relies on cyclic redundancy checking. When a recipient node calculates different checksum than the transmitting node indicated, CRC error will pop-up. This signifies a wrong data transmitted in the bus. Some causes include congestion, reflections and standing waves and EMI noise.
Fixes worth to try – Check the CAN bus utilization, check the termination if present or effective and route CAN wires away from electrically noisy devices and other wires.
- Bit Stuffing Error – if there is five consecutive logic 1 or logic 0, the transmitter will automatically insert an opposite polarity. This is called bit stuffing. The receiving node expects this implementation. If this is not followed, it will trigger a bit stuffing error. The possible causes are 1) clock drift occurrence that de-synchronize the transmitter and receiver, 2) a protocol mismatch, 3) mixing of CAN (such as slow speed, high speed and FD in a single bus), 4) Signal interference and 5) electrical noise or EMI
Fixes worth to try – review the clocking strategy and protocol to use, ensure all nodes in a bus to have the same baud rate (not mixing of different CAN types), route CAN wires away from electrically noisy device or harness and check if termination is present or effective
- Form Error – when a receiver detects a different frame structure, it will trigger a form error. Possible cause is mixing of standard frame and extended frame structures. Such as the transmitter uses the extended frame but the receiver is expecting a standard frame.
Fix worth to try – check all CAN nodes to have a common message frame expectation
- Overload Frame/Error – this error will show up when the bus is congested. The overload flag has 6 dominant bits and followed by 8 recessive overload delimiter. The cause of this error is bus congestion or overload.
Fix worth to try – check the utilization of the CAN bus. A healthy bus must have a utilization of less than 50%
What is Baud Rate Mismatch
A baud rate mismatch happens nodes in a bus is not using the same CAN baud rate. For instance, node A is set to 250kbps, node B is 500kbps, node C is 1Mbps and so on.
CAN Bus Topologies
Linear Bus Topology
All devices are tapped to a single two-wire line using short connections. There is 120 ohm terminating resistor at the end of the bus to avoid signal reflections.
Daisy Chain Topology
This is a modified linear topology. In linear, there is a single two-wire lines wherein each node taps to it via a short connection. On the other hand, in daisy chain, the first node will pass the two-wire line to the second node via each connector the second node will do the same to the third node and so on. The termination resistors are still applied to the left end and to the right end of the bus.
Star Bus Topology
There is a central hub wherein all nodes going to connect. In this topology, individual CAN devices connecting to the hub is called stub. There are two variants; active star and raw star.
- Active Star – the central hub is intelligent like a smart CAN hub, switch or gateway. The central hub will receive the signal from each stub and it will do processing before transferring to the other nodes.
- Raw Star – the central hub is just a passive device. It is just like a connecting hub. It will not process the signal from each stub, instead pass it right away to the other stubs.
Tree Bus Topology
It is just a combination of linear and star topologies. This suitable for a very huge CAN network.
CAN Communication Hardware Requirement
- Select the correct CAN chip
- Follow the CAN chip recommendations such as voltage level, passive recommendations (resistors and capacitors), protections (like ESD and surge) and grounding.
- In the PCB, ensure the CAN high and CAN low traces are routed as differential pair and route them away from noisy components and traces.
- Ensure a solid good grounding in the PCB.
- Do not mix CAN types (such as classical and FD or with the low speed one)
- Do not mix baud rates is a CAN bus
- Put termination resistors at each end of the bus
- Ensure the termination value is correct (a 60-ohm must be measured across CAN high and CAN low)
- Route the CAN wires away from noisy devices
- Do no bundle CAN wires with noisy harness or high voltage and high current wires
- Use a correct wire (such as twisted pair, shielded and suitable wire gauge)
How to Qualify & Validate a CAN Bus?
Check the Hardware Integrity
Ensure all the hardware aspects are correctly done such asproper selection of CAN chip, following the datasheet recommendations, correct PCB routing, correct grounding, do not mixing of CAN types, no baud rate mismatch, ensure there is termination resistors and its location and values are correct, not to route CAN wires in the noisy path, not bundle CAN wire with noisy or high voltage and current harness and ensure to use right connections (such as twisted or shielded and sufficient wire gauge).
Check the Signal Integrity
Using a scope, quantify the CAN high and CAN low signals with respect to a local ground (common mode). There must be no ringing and overshoot in the waveforms. The waveform must not show sluggish rise time. Do the same for the differential signal. The ideal waveforms and levels must look like below.
Another way to check the signal integrity is through eye diagram. High end oscilloscopes can perform this analysis. The bigger the eye means a very good CAN bus while a smaller eye denotes a concerning CAN bus.
Check the Data Integrity
This is about ensuring the CAN message transmitted is received to the other end. Using a CAN analyzer like Kvaser can check the data integrity. If there is a problem, CAN error frames will show up. Part of this is to check the CAN bus utilization. A healthy CAN bus must have a utilization of not more than 50%.