CAN Bus Baud Rate vs Cable Length
On CAN, speed and distance trade against each other in a way that trips up anyone who assumes faster is always better. Run a bus too fast for its length and it fails arbitration in ways that look random; run it slower and a long bus becomes rock solid. This page explains why the maximum cable length shrinks as the baud rate rises, the arbitration-timing reason behind that hard physical limit, and how to choose a rate that every node can share, because on CAN every node must agree on the same bit rate.
CAN Baud Rate and Distance in one line: On a CAN bus, baud rate and cable length trade off against each other: the faster the bit rate, the shorter the maximum bus length. The limit comes from arbitration, which requires a bit to travel to the far end and back within one bit time so all nodes agree on the level. Every node on a segment must be set to the same baud rate, and common industrial rates are 125, 250, and 500 kbit/s.
Why Faster Means Shorter
The distance limit on CAN is not a cable-loss problem the way it is on some networks; it is a timing problem rooted in arbitration. During arbitration every transmitting node must read back the actual bus level within the same bit it is sending, and for that to work the signal has to propagate from one end of the bus to the farthest node and, in effect, back again inside a single bit time. As the baud rate rises, the bit time shrinks, so the round-trip propagation budget shrinks with it, and the bus must be physically shorter to fit.
That is why the well-known figures line up the way they do: the highest CAN rates are usable only over short runs, while dropping to a slower rate buys a much longer bus. A machine cabinet with all nodes close together can run fast; a distributed system spread across a large skid or vehicle runs slower to reach every node. The exact numbers depend on cable, transceiver delay, and bit-timing configuration, so treat published length-versus-rate tables as guidance and confirm your own worst-case node placement rather than assuming the maximum.
Every Node Must Share the Same Rate
CAN has no auto-negotiation of speed in the base standard, so every node on a segment must be configured for the identical baud rate. A single node set wrong does not just fail to talk; because it misreads bit boundaries it generates error frames that disrupt the whole bus, so one mismatched device can take down communication for everyone. When a previously working bus dies right after a device is added or replaced, a baud-rate mismatch on that device is one of the first things to check.
Higher-layer protocols narrow the choices for you. J1939 for heavy-duty vehicles standardizes on 250 kbit/s for its classic bus, which is why gensets and engines commonly present data at that rate; CANopen and DeviceNet define a small menu of supported rates that all nodes select from. Some CANopen and DeviceNet devices support automatic bit-rate detection during startup, but that is a protocol feature, not a property of raw CAN, and it still lands the device on one of the fixed rates.
Setting the rate is only half of matching a bus; the sample point inside each bit also has to be consistent enough across nodes that a bit sampled at the far end still lands in the intended window. Most controllers default to a sensible sample point, but on long or fast buses with mixed hardware it is worth confirming, because two nodes at the same nominal baud rate but very different sample points can still fail on a long run. This is the CAN equivalent of matching parameters on an RS-485 serial link before expecting devices to talk.
Choosing a Rate for a Real Network
The design question is not the fastest rate the hardware supports; it is the slowest rate that still carries your traffic, because slower rates give margin. Estimate the bus load from the number of periodic messages and their rates, confirm it leaves headroom for high-priority bursts, and then pick the lowest standard rate that fits with room to spare. A lightly loaded bus tolerates marginal physical layers far better than a heavily loaded one, and it leaves you slack for future nodes.
If a protocol dictates the rate, as J1939 largely does, your job shifts to making the physical layer support that fixed rate over your actual distance rather than choosing the rate. That means keeping stub lengths short, terminating both ends correctly, and confirming the farthest node still sits inside the timing budget for the required rate. A J1939 engine or genset run that is marginal is usually marginal on physical layer, not on speed selection, since the speed is not yours to change.
Once the rate is fixed and the bus is stable, it stays fixed for the life of the network, and changing it later means touching every node. That permanence is a good reason to build in margin at design time. When the data leaves CAN through a gateway toward a monitoring system, the baud rate no longer matters upstream, but its consequences do: a bus run too fast for its length shows up above the gateway as intermittent missing data, which is why getting the rate-versus-distance decision right at the wire pays off for the whole data chain.
Frequently Asked Questions
Why does a higher CAN baud rate limit cable length?
Because CAN arbitration requires a bit to propagate to the farthest node and back within one bit time so every node agrees on the bus level. A faster baud rate shortens the bit time, which shrinks the propagation budget and forces a shorter bus. It is a timing limit set by arbitration, not simply cable signal loss, which is why the fastest rates are only usable over short runs.
Do all nodes on a CAN bus need the same baud rate?
Yes. Base CAN has no speed auto-negotiation, so every node on a segment must be set to the identical baud rate. A single mismatched node misreads bit boundaries and generates error frames that disrupt the entire bus, not just its own traffic. Some CANopen and DeviceNet devices can auto-detect the bit rate at startup, but they still settle on one of the network's fixed standard rates.
What baud rate does a J1939 genset use?
Classic J1939 for heavy-duty vehicles and engines standardizes on 250 kbit/s, so gensets and engine controllers commonly present their data at that rate. Because the rate is fixed by the protocol, the design task is making the physical layer support 250 kbit/s over the actual cable distance, with correct termination and short stubs, rather than selecting a rate yourself.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.