CAN VS CAN FD - Know The Difference | Simple Explanation

When comparing Classical CAN with CAN FD, the fundamental difference is that one is just advancement to the other. The significant difference lies in the data rate that both of them offer.

The Classical CAN offers 11-bit (standard) and 29-bit (extended) data rates, whereas CAN FD as the name suggests, offers flexible data rates, ranging from 0-64 bytes per frame. BOSCH had developed both these technologies to support the ever-growing need for data and technology in the automotive industry.


As the name suggests, the basic or most popularly known as the classical CAN was the initial invention. BOSCH originally made a Controlled Area Network Bus (CAN Bus), a communication protocol (a digital data network) for automotive applications. With vehicles becoming innovative and multiple ECU's coming into the picture, there was a need to introduce a communication method that could justify the ever-growing demand for complexity, speed, and loads of data. With time the advancement took the beast mode, and here is when CAN bus played an essential role as it would not have been fair to lay the vehicle with kilometres of wire just for communication between different modules.


On the other hand, CAN FD was released as an advancement to the original CAN-Bus protocol when the features offered by the Classical CAN started falling short of the technology it had to support. CAN Flexible Data rate (specified in ISO 11898-1:2015) is practically a more capable CAN. This flexible signal transmission provides automotive electronics' communication with increased bandwidth and all the required functionality cost-effectively. Moreover, it offers upgradation to almost every feature CAN holds and is a better alternative for more advanced data and bandwidth requirements.


The classical CAN 2.0 bus has many features that make it an ideal choice for applications where the number of ECUs is more and the bandwidth utilization is less. Classical CAN bus supports a maximum message payload of 8 bytes per frame at a maximum data rate of 1Mbps. CAN FD supports a flexible message payload, ranging from 0, 8, 12, 16, 20, 24, 32, 48, 64 bytes per frame at 2, 5 and 8 Mbps of data rates. Also, the CAN FD Protocol has two independent bit rates for the arbitration and data phases. The arbitration phase uses the same bit timing as the Classical CAN, but the data bit rate is either similar or higher than the arbitration bit rate.


The below table consists of a few basic differences between a Classical CAN and CAN FD:




There are many more differences that can be understood by knowing both the technologies in detail. The knowledge of frame formats, error handling techniques, and other features will give you a clearer picture of how one differs from the other.


Frame Formats:



Frame Format for a standard CAN bus (11 bit)





  • SOF: Start of Frame. Marks the beginning of the data frame. (A dominant 0)


  • ADDRESS FIELD: This field decides the priority of the data. The lower the address higher the priority. An address with a maximum number of dominant "0" will hold the highest priority. No two nodes can transmit the same message address at the same time.


  • RTR: Remote Transmission Request is used to request data from the nodes that are not needed to send the data continuously. This is used if any node wishes to communicate with another specific node. This directly reduces congestion on the bus as direct communication takes place between the nodes.


  • ARBITRATION: The arbitration process is the one that helps in deciding which node gets to play master for a given point of time. Any node that transmits a logical "1" when another node transmits a logical 0 "drops out" or loses the arbitration. This means that the node that transmits the first "1" loses arbitration; a dominant "0" always wins. The node that fails arbitration re-queues its message for re-transmission, and the CAN frame bit-stream continues without error until only one node is left transmitting.


  • IDE: Identifier Extension Bit is for future use/extension. A recessive IDE will result in another 18 bits of the address.


  • RSRV: Reserve Bit. As the name suggests, it is kept for future up-gradations.


  • DLC: Data Length Code (0-8 bytes).


  • DATA: User-defined data (0-64 bits).


  • CRC: Cyclic Redundancy Check for error/data corruption detection.


  • ACK: Acknowledgement by the receiving end.


  • EOF: End of Frame (7s bit recessive "1" s)



Frame Format for CAN FD




The Frame Formats for classical CAN Bus and CAN FD may not seem very different. But a few added fields in a CAN FD frame format are not present in the classical CAN bus.


  • RRS: Remote Request Substitution (always a dominant 0). The remote frames are not at all supported in CAN FD. (In classical CAN, there is RTR (Remote Transmission Request) for identifying the data frames and remote frames)


  • FDF: Flexible Data Rate Format (always a recessive 1) used to indicate Flexible data frame format usage.


  • EDL: Extended Data Length (always a recessive 1) for managing larger payloads and faster bit-rates in CAN FD.


  • BRS: Bit Rate Switch helps determine the bit rate of a data frame.

  1. Dominant 0 signifies that the arbitration rate for the CAN FD data frame is up to 1Mbit/sec.

  2. Recessive 1 signifies a higher/faster arbitration rate for the CAN FD data frame ranging up to 5Mbit/sec.


  • ESI: Error State Indicator

  1. A dominant 0 indicates the error-active mode.

  2. A recessive 1 indicates the error-passive mode.


  • DLC: Data Length Code is a 4-bit code in CAN FD which denote the number of data bytes in the frame. (DLC values ranging from 1001 to 1111 are used to specify the data lengths of 12, 16, 20, 24, 32, 48, and 64 bytes).


  • CRC: The Cyclic Redundancy Check is 17 bits long for up to 16 bytes of data or 21 bits for 20-64 bytes. Its length depends upon the length of EDL and DLC bits. CAN FD always uses 4-fixed stuff bits that improve communication reliability.



Features of Classical CAN and CAN FD:


Classical CAN


  • CAN uses pair of twisted wire cables.

  • It offers easy and simplified handling.

  • Multiple ECUs can be connected on the same CAN-BUS.

  • Developed to support and enable high speed and efficient communication in automobiles.

  • It has reduced weight and wire costs.

  • Error reduction.

  • A quick exchange of data. Uses arbitration process; hence top priority data get access of the bus.

  • Scope for upgradation.

  • Standard CAN 2.0A allows 11Bit data transmission (meaning, a total of 2048 different unique messages can be introduced).

  • Extended CAN 2.0B allows 29Bit data transmission (that sums up to 536+ million messages).


In addition to all the features that the Classical CAN offer, CAN FD has:


  • Flexibility to switch between faster and slower data rates.

  • Increased Protocol efficiency.

  • Reduced protocol overhead.

  • Allows more data to fit into a single message.

  • Better reliability.

  • Improved network bandwidth.

  • Up to 30 times more efficient and faster communication between multiple ECUs.

  • Decreased number of undetected errors with advanced CRC.



Influx provides you with a wide variety of data loggers that support these technologies to cater to the automotive industry's ever-changing needs.

The Influx Rebel CT CAN FD is a compact data logger with gateway functionality and is an ideal choice for applications that requires vehicle CAN 2.0, CAN FD and LIN network data.

The Rebel CT CAN FD logger can optionally be upgraded to include GNSS, 3D accelerometer, 3D Gyro, Wi-Fi and 4G LTE.


Recent Posts

See All