Noise resilient, hot-pluggable communication bus over long cables?

Question

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.

Answer 1

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.

Drawbacks:

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.

Advantages:

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.