1
\$\begingroup\$

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?

schematic

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.

\$\endgroup\$
  • \$\begingroup\$ Use udp/ip via a switch \$\endgroup\$ – Gregory Kornblum Mar 4 '18 at 22:10
  • \$\begingroup\$ But does UDP not lack all the error-handling I'm requesting in the above? :-) As far as I understand it, UDP is used when transfer speed is paramount - on the cost of error checks. Anyways, thanks for your answer! \$\endgroup\$ – Johan E. T. Mar 4 '18 at 22:20
  • \$\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\$ – Gregory Kornblum Mar 4 '18 at 22:22
  • \$\begingroup\$ It's true, that the moving termination makes the implementation a lot easier! Do you have experience with how UDP/IP based communications perform in noisy environments? \$\endgroup\$ – Johan E. T. Mar 4 '18 at 22:25
  • 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\$ – Sparky256 Mar 4 '18 at 22:49
0
\$\begingroup\$

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.

\$\endgroup\$
  • \$\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\$ – Sparky256 Mar 4 '18 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 Mar 4 '18 at 22:56
  • \$\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\$ – Sparky256 Mar 4 '18 at 23:14
0
\$\begingroup\$

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.

\$\endgroup\$
  • \$\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 Mar 12 '18 at 12:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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