I'm working on a setup, where we need communication between a master device and several slave microcontrollers distributed out in different boxes connected by "long" cat5e cables (3-10 meters) The microcontroller boxes (MC-boxes) should be hot-pluggable, such that the master device can communicate with whatever is connected at any time. The MC-boxes need not to communicate with each other.

We have achieved this in the comfortable and controllable surroundings of our office in an I2C-based setup, utilizing the TI's P82B715 I2C extenders. However, we've observed that this solution is not reliable in noisy environments where the I2C-bus locks up within hours or days requiring a hard reset.

Thus, I have started looking into differential signaling protocols due to their inherent noise resilience. CAN-bus seems especially interesting due to it's error handling capabilities. And, as far as I have read, it should be possible to make devices on a CAN-bus hot-pluggable (several comments in this post also states so). However, in our application, the bus cannot be laid out beforehand, but should be extended as MC-boxes are dynamically added. The CAN spec states that the bus should be terminated by two 120Ω resistors, which makes the dynamic expansion troublesome. So, how can I achieve something like that, I have tried to depict below?


simulate this circuit – Schematic created using CircuitLab (PS: The boxes don't have to be daisy-chained like shown above)

Thus, my questions are:

  • How can I achieve an extendable CAN-bus, that retains the constant impedance on the signal lines as required by the spec, when new 'boxes' are added or removed?
  • Can I achieve the above with a completely different protocol?

I hope you are able to help!

Edit - Clarifications: - The master unit will be connected to the internet, so I have some security concerns with using IP-based protocols such as TCP and UDP. - The boxes should be water-proof, so all electronics must be kept inside the boxes.

  • 2
    \$\begingroup\$ Use udp/ip via a switch \$\endgroup\$
    – user76844
    Commented Mar 4, 2018 at 22:10
  • 1
    \$\begingroup\$ It's plain and simple. Also very reliable, though tjere is no 100%. Best part it's point to point, so no moving termination. But yes, you would have to take care of errors by yourself \$\endgroup\$
    – user76844
    Commented Mar 4, 2018 at 22:22
  • 2
    \$\begingroup\$ I2C has a software reset option, to detect if the SCL is locked low beyond a time limit, but is must be in the software for each device. \$\endgroup\$
    – user105652
    Commented Mar 4, 2018 at 22:49
  • 1
    \$\begingroup\$ Maybe 10base2 would work for this? Although the combination of "hotplug" and "IP67" is going to make whatever solution you choose expensive. Especially if you need to "wetplug". \$\endgroup\$
    – pjc50
    Commented Mar 5, 2018 at 10:35
  • 1
    \$\begingroup\$ If you have a waterproof cabling solution, you can have a waterproof termination solution, too. \$\endgroup\$
    – user57037
    Commented Mar 6, 2018 at 7:54

4 Answers 4


The boxes should be water-proof, so all electronics must be kept inside the boxes.

Then I'd seriously consider radio instead of wired:

  • If you need full networking, WiFi with ESP32

  • If you don't, there are lower power solutions like ZigBee or nRF24L01.


It uses more power than wired, and it can't use the signal cable for power supply. Transmission is a bit less reliable than wired, ie sometimes it will have to retransmit a lost packet which results in delays, which will cause problems if you need accurate time synchronization or consistent short response times between your boards. The boards will need configuration (like wifi network ID). Radio doesn't work under water.


Boards can be placed on moving objects. There is nothing to plug, so it is "plug" and play. No need for expensive connectors, very good immunity to conducted interference because there are no wires, and built-in galvanic isolation.


Important clarification: Protocols have a hardware layer and what I'll call a message layer (it sometimes is data link layer or other names). The physical layer defines termination and signalling levels. The message layer can just talk about addressing a device and figuring out who can send a message, or it can go all the way to detailing what kind of messages are allowed and how to handle error checking. CAN has a physical layer and I believe there are a few message layers you can use. CANopen is a popular message layer, but automotive companies each have their own as well.

Depending on the intelligence of transceiver you use, you can run any message protocol on any physical layer. There are no rules. You can use a CAN transceiver and just send whatever messages you want.

Regarding CAN physical layer, the end termination is important. There are two ways to handle the termination, and it sounds like the better one for you will be to have no termination on the devices, but have a separate termination connector that gets plugged in at the start and end. So in the drawing you have, just move the 120 Ohm terminators outside the boxes, the termination can just be a connector and resistor.

The CAN message layer is a solid protocol, very simple and noise resistant, but it is pretty slow, and the protocols that are designed for it are made for cars where they just need to send very small amounts of data, safely and occasionally.

RS485 is another common differential, multidrop, asynchronous physical layer. I believe it can run at higher speeds than CAN, but it is less strongly specified and there really is no dominant message layer.

You mention I2C, so you should know that it is really inappropriate as a long distance physical layer. If you try to drive I2C too long, you will start to run into the clock and data lines falling out of alignment.

Imagine I send my clock out at t=0, it travels at 6 inches per nanosecond and arrives 20 feet away at t=40 ns. The receiver now sends data back to me, and even without accounting for any internal delays or capacitance, 80 ns have already passed. I2C, SPI and other synchronous protocols are intended for short distances.

Ethernet protocols, like UDP or potentially EtherCAT, are really great for long distance messaging. Ethernet is magnetically isolated so there is no worry about isolation issues, which makes life much easier. Grounding problems are a whole other beast that deserves its own thread.

The Ethernet physical layer has CRC error detection on the packets, so errors are identified, although they are not corrected. UDP has no built in error detection, but is much simpler compared to TCP, which has full packet re transmits when there is an error.

  • \$\begingroup\$ RS-485 so far has a top ideal speed of 30 Mbps, over an un-shielded twisted pair. RS-485 needs a ground wire for signal common, else a DC drift can occur. \$\endgroup\$
    – user105652
    Commented Mar 4, 2018 at 22:46
  • \$\begingroup\$ The only protocol that does not require a ground wire is Ethernet, and other similarly isolated protocols. Ethernet uses differential signals that drive into a transformer to provide isolation. I believe I've seen similar setups for CAN, but it is not the standard. Thanks for the speed info. \$\endgroup\$
    – pscheidler
    Commented Mar 4, 2018 at 22:56
  • 3
    \$\begingroup\$ Most IT and network engineers will automatically use Ethernet, and as many routers as needed. It is as close to plug-and-play as you can get. Most MPU's have a driver library you can download, but do not support 1 GB Ethernet due to extreme demand on the data bus. \$\endgroup\$
    – user105652
    Commented Mar 4, 2018 at 23:14

How can I achieve an extendable CAN-bus, that retains the constant impedance on the signal lines as required by the spec, when new 'boxes' are added or removed?

You cannot in the standard way. CAN bus is not suitable for random topologies. It is CAN bus and requires a bus topology with short stub length* or a low bitrate.
Combined with the termination, can bus cannot be made hot plug, you can make it pluggable, but communication will still halt when adding or removing a node since you will have to split the bus or remove termination.

However, you could do it by making CAN hubs, simple repeaters with a transceiver pair, so each stub will have terminator resistors and their own 1 to 1 tranceivers. It will take a hit on your maximum length.

Can I achieve the above with a completely different protocol?

Yes, you can use a hardware layer that has tranceivers for each stub. For example: USB or Ethernet. But you will need switches or hubs.
You have drawn a master node, perhaps Modbus TCP/IP is a solution.

*length from bus wire to node on T-split.

These are all layer 1 considerations. There still are layer 2 challenges with possible arbitration problems. You will need to use dynamic assignment of node ID's For example j1939 does this, but so does DHCP.

  • 1
    \$\begingroup\$ Hot-plugging in the middle of the bus should be possible, given that the mechanical parts allow it. CAN is fairly insensitive to short stubs. At worst case you'd get some error frames temporarily. The challenge will be to design a hardware that allows the hot-plugging without cutting off CAN Hi/Low. \$\endgroup\$
    – Lundin
    Commented Mar 12, 2018 at 12:58
  • \$\begingroup\$ CAN can work with surprisingly long stubs if you can accept a lower bit rate. NMEA2000 is specified for stubs up to 6m. (although is limited to 250kb/s) \$\endgroup\$ Commented May 16, 2023 at 12:27

CAN topology is similar to that of the old 10Mbps coaxial network or RS-485. Termination at both ends of the bus, nodes connect with short stubs in the middle. The number of nodes is of course limited and they can be hot-plugged. Another variant is the J1939 between trucks and trailers; hot-plugging support is a must.

In a master-slave setup I'd not recommend using CAN. CAN makes sense when any of the nodes must be able to initiate communication (there is no master), you have frames with different priorities and priority inversion must be avoided. If these features are not required, the somewhat sensitive arbitration mechanism of CAN is not needed. RS-485 can be much more robust and bridge much longer distances. Also consider that creating CAN controller drivers and implementing the standard upper layers are not trivial.

Another idea for bus topology is the 10BASE-T1S or 10BASE-T1L. These standards were developed for automotive use to replace CAN. There are very few transceivers available as of now, they're coming in the following years. Eventually they can be an affordable, faster and more flexible option to CAN. An SPI-connected MACPHY can be integrated into existing systems easily, but I guess software won't be trivial.

  • \$\begingroup\$ Not sure which 10Mbps network you mean. They do not allow stubs, or at least, not more than about an inch, which is useless. The other networks you suggest allow far longer stubs. And you are mixing protocols with physical interfaces. CAN is both an interface and protocol, but you don't have to talk CAN protocol over CAN bus. RS-485 is also a bus and you can talk anything you want over it, like morse code. The hot-pluggability of your suggestions are questionable, it cannot be dynamically expanded at the ends by plugging cables. \$\endgroup\$
    – Justme
    Commented Jan 22 at 7:52
  • \$\begingroup\$ Using CAN without the CAN protocol does not make sense. The transceiver is only driving the dominant state actively, the recessive state is set by the termination resistors. This is crucial for the CAN arbitration mechanism, but also limits the speed and the bus length. If you're not using the CAN protocol, RS485 is better. There is almost always some UART-based protocol implemented on top of that, but you can do whatever you want... \$\endgroup\$
    – vjalle
    Commented Jan 22 at 8:05
  • \$\begingroup\$ Hot-plugging works on CAN. Partial networking is a mechanism to selectively shut down nodes on CAN while operating the rest of the bus. The SAE J1939 extension explicitly specifies hardware-level disconnection of bus segments with one or more nodes. The 10Mbps protocols mentioned above are relatively new ones designed for automotive to replace CAN. Tramsceivers are already available from Canova. \$\endgroup\$
    – vjalle
    Commented Jan 22 at 8:11
  • \$\begingroup\$ Using CAN PHY with some other protocol than CAN may make sense. Just like using RS-485 in dominant/recessive modes only, instead of push-pull output. It's just a robust differential version of single-ended open-drain or open-collector bus. But still, 10MBps coax Ethernet did not really have stubs, not 10Base-5 nor 10Base-2. \$\endgroup\$
    – Justme
    Commented Jan 22 at 8:26

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.