# What is the limiting factor for a CAN bus to exceed 1Mbps bandwidth?

Why can't CAN baud rate increase beyond 1Mbps

• Depends on standards and drivers used. There are faster versions but there are other differences, Commented Apr 29, 2019 at 20:45
• My question is why can't we achieve higher speeds like upto 100Mbps using CAN? Commented Apr 29, 2019 at 20:47
• Ignition and RF Immunity and delay contention on the bus Commented Apr 29, 2019 at 20:49
• Commented Apr 29, 2019 at 21:12
• the CAN bus has no overt synchronization, except for detecting collisions. Commented Apr 30, 2019 at 2:37

CAN is an open collector technology – the protocol could not work otherwise. This means that the recessive state of a CAN transceiver is not actively driven. The termination resistors together with transceiver input capacitance and cable capacitance create an RC time-constant discharge when an actively-driven dominant bit on the bus transitions to an un-driven recessive bit. For signaling rates greater than CAN's 1Mbps, a technology that actively drives the bus in both states such as RS-485 is required to facilitate the bus transitions required for high-speed signaling rates.

Ultimately, the answer to the question is how the CAN protocol is implemented at a physical level. Change that protocol and a higher data rate can be used.

... the CAN protocol implements a non-destructive bitwise arbitration scheme that allows multiple nodes to arbitrate for control of the bus. Therefore, it is necessary for all the nodes to detect/ sample the bits within the same bit time. The relationship between propagation delay and oscillator tolerance effect both the CAN data rate and the bus length.

Two masters on either end of the CAN bus must be able to communicate and arbitrate which one has the bus, while each are on the bus at the same time.

If the bus length is 30 m, the time it takes to propagate the signal over the bus is: $$t_{BUS} = 30\ m @ 5.5\ ns/m = 165\ ns$$

Assuming the input comparator delay is $$\t_{CMP}\$$ = 40 ns and the output driver delay is $$\t_{DRV}\$$ = 60 ns for all devices.

The round trip time for a bit on the physical bus will be:

$$t_{PROP} = 2(t_{BUS} + t_{CMP} + t_{DRV}) = 2 (165\ ns + 40\ ns + 60\ ns) = 530\ ns$$ $$TQ = 530\ ns/6 = 88.33\ ns$$ $$t_{BIT} = 10\times TQ = 883.3\ ns$$ $$f = 1/t_{BIT} = 1 / 883.3\ ns = 1.13\ MHz$$

The maximum rate is governed by bus length, line capacitance, connected nodes and the drivers selected by the protocol. In principle at 30 m, CAN (ISO 11898) could do 1.13 Mbps if everything was perfect.

The longer the bus, the slower the data rate. But a shorter bus would mean a higher rate. CAN bit rate vs. bus length:

Both referenced documents go into this at greater length.

CAN (ISO 11898) can transfer up to 8 bytes at 1 Mbps with a protocol based in the 80's. With today's vehicles, there is a need to transfer more data (64 byte packets), but at 1 Mbps, 64 bytes would take up to large of a time slot, possibly delaying vital data.

CAN FD (Flexible Data-Rate) is an extension to the original CAN bus protocol (ISO 11898-1). It is meant to run on existing CAN buses and eventually replace CAN.

The protocol starts out at the CAN 1 Mbps (500 kbps, etc.), with the possible arbitration process between multiple CAN and CAN FD masters, but when the CAN FD master obtains the bus, the data transfer rate accelerates to 5 Mbps to CAN FD slaves. At this rate, 64 bytes can be transferred in less time than an 8 byte CAN 1 Mbps packet. This means there is no timing conflict with existing CAN transfers. Once the CAN FD master gives up the bus, any CAN or CAN FD master can obtain bus.

The true answer depends upon the 1 Mbps arbitration process for a 40m CAN bus, but once the bus is obtained the bandwidth can be accelerated dependent on bus length, line capacitance, number of connected nodes and the drivers. The CAN FD bandwidth is 3-8 times the classic CAN bandwidth.

It can. Meet CAN-FD.

Why was a new protocol needed? CAN is a multi-master bus with arbitration and error reporting. These features limit the data rate based on the cable length, since it takes a certain amount of time for the signal to make a round trip between the two farthest nodes. That, along with backwards compatibility requirements, led to CAN-FD.

Classic CAN at 1 Mbps is limited to a 40-meter bus length. (In practice, I think it's lower due to stray capacitance.) At 100 Mbps, you'd be lucky to have even half a meter of usable bus length, which is not enough for automotive and industrial applications.

It's because the CAN 2.0B standard did not specify any higher in order to reduce hardware costs and still meet the various requirements of the standard (like distance and noise immunity). It's not a technical barrier.

The standard was written that way probably since they deemed the extra speed unnecessary for the intended application, and specifying a higher speed needlessly would increase the cost of all the hardware supporting the standard when the capability would be underutilized.

If the standard is written that way, few IC manufacturers will bother trying to exceed it since there's no point. It's not really a technical barrier.