I will first try to explain the layout as good as possible.

I have a device (left side of the image) that has outgoing CAN bus and incoming CAN bus connections. Physically this is only one CAN bus in a "loop", so that begin and end of the CAN bus are inside the device and therefore both terminating resistors are inside the device.

The device is connected to a terminal strip, and from there ETHERNET cable (CAT5e) is used to connect to the stubs. At the last stub, there is also a terminator-connector that routes the outgoing CAN bus to the incoming CAN bus.

CAN bus speed is 500kbit/s or 1000kbit/s


  • approx. 3m from terminal strip to stub 1
  • approx. 0,5m from stub 1 to 2, 2 to 3, 4 to 5 and 5 to 6
  • approx. 1m from stub 3 to 4
  • no lenght to be calculated from stub 6 to "terminator"

The cable is connected to the devices at the stub directly, so no separate "side connection"from the main cable.

I am not 100% sure about the ILI and ILO signal. I only know these are used to measure resistance, to measure if the whole loop is connected correctly. So I assume it is a low DC voltage and current used to do the resistor measurement.

For simplification of the drawing I left out the +12V / 0V power lines. These are in the green/green-white twisted pair.

CAN bus layout

As you can see in the image, the outgoing CAN and incoming CAN bus are not in their own twisted pair.

So, my question is:

Will this kind of CAN bus layout be likely to cause problems, especially because of the outgoing and returning signals are in one twisted pair ? What effects can I expect on such CAN bus layout ?

I can imagine that the normally differential CAN bus signals are not synchronous in the blue twisted pair, but slightly asyncronous possible causing a problem on some packets ?


1 Answer 1


The real question is, why would you want to do this?

The whole point of twisted pair is to provide (as near as possible) an identical path for two differential signals. Being differential, any common-mode noise is picked up equally by both in the pair, which means that the high common-mode rejection of typical diff input circuitry successfully eliminates it.

Running diff pair signals on separate pairs completely defeats this. If the diff pairs are twisted at different rates (likely, examine a CAT6 cable closely), the result will be even worse.

Will this kind of CAN bus layout be likely to cause problems, especially because of the outgoing and returning signals are in one twisted pair?

I see CAN bus IN and OUT on the same cable commonly, but only ever as distinct pairs. Since both are supposed to be in their own pairs, cross-talk between the pairs is minimal and the receiver's common-mode rejection is easily able to reject any cross-coupling that does occur. But if these signals are not in their own pairs, then coupling will increase, and it will not be balanced between high/low, so the receiver may not be able to reject the (much larger) common-mode component and will not reject the singular conducted component at all. er.go., quality will decrease.

What effects can I expect on such CAN bus layout?

Anything from "it still seems to work ok" to "it no longer works at all."

Part of this ambiguity comes from the "stubs." If a "stub" introduces another device to the bus, then it is a "T" connection, period. It doesn't matter if these T stubs are 0.1mm long or 1m long - a stub is a stub. If you have devices plugging into the middle of the cable, they are going to introduce stubs, which introduces more cable parasitics. If you think about it, these stubs conduct the signals in parallel for a short time, which means that their introduced parasitics are also in parallel during this time. Anyways, CAN is pretty robust in that it typically supports a large number of devices, so provisions have been made to accommodate typical use. But from a designer's standpoint, you should be aware of what these stubs do to the signal and be prepared to adjust them (characteristic impedance matching) if needed.

I can imagine that the normally differential CAN bus signals are not synchronous in the blue twisted pair, but are slightly asynchronous, possibly causing a problem on some packets?

Possibly. At 1Mbit, each bit passes through the cable in 1µs. The cable parasitic inductance and capacitance will work to degrade and delay these fast transitions. Stubs add some discontinuities since the signal essentially splits for a short section. Running wires out-of-pair will add some delay discrepancies also. The only way to know for certain how this all affects the particular implementation would be to use an oscilloscope to actually capture and measure these delays.

For short cabling runs, the difference will be so small as to not be an issue. But as the frequencies get higher and cables get longer (and stubs get longer), this becomes more problematic.

If a signal bit transitions in 1µs, for the edge to have a nice and clean look, 10-100x or more bandwidth is required. So even though the bit rate is (just) 1M/s, "good" transitions might include frequency components in the 10-100MHz range. Using too long, poor-quality, or mis-wired cabling will decrease this bandwidth, resulting in slower and "dirtier" transitions. The receivers are pretty good and cleaning up this undesired effect, but there are limits.

So, choose a high-quality cable designed for CAN, PROFIBUS, or Ethernet and wire is properly, and you'll be fine. But choose a no-name cable and mis-wire it, and this is asking for trouble.

  • \$\begingroup\$ For the "why do you want to use it" I can be short. Someone every engineered it like this, and I have to work with it now. My best educated guess is that the engineer took some ethernet connectors suitable for the stub devices to be connected, simply because it's easy to mount. Not carrying any knowledge about differential busses and why twisted pairs are ever invented. Thanks for the extensive answer. \$\endgroup\$
    – bart s
    Jul 28, 2022 at 14:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.