5

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.

Kevin Reid
  • 7,444
  • 1
  • 25
  • 44
Johan E. T.
  • 155
  • 7
  • 1
    Use udp/ip via a switch –  Mar 04 '18 at 22:10
  • 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! – Johan E. T. Mar 04 '18 at 22:20
  • 1
    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 –  Mar 04 '18 at 22:22
  • 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? – Johan E. T. Mar 04 '18 at 22:25
  • Ethernet is very stable because it's isolated on both sides, and phy uses all kinds of magic to be even more immune. And you can use shielded cables. I think it's the best. –  Mar 04 '18 at 22:26
  • Do you maybe have some specific links to appropriate switches and IC's that I can interface with the microcontrollers, such that I can look further into it? :-) – Johan E. T. Mar 04 '18 at 22:34
  • Mac/phy look up for microchip. Switch- i don't remember, but start with tp-link or something –  Mar 04 '18 at 22:35
  • Have you already considered RS485? – user57037 Mar 04 '18 at 22:46
  • 2
    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. –  Mar 04 '18 at 22:49
  • You can also sometimes unlock I2C by just sending out some clock pulses. One of the devices is probably out of syc with the master. If you just feed it enough clocks, it will go back to waiting for commands. – user57037 Mar 04 '18 at 22:53
  • UDP is point-to-point. You can't daisy chain it. – user57037 Mar 04 '18 at 22:55
  • It is pretty easy to have a termination header, and just install a removeable termination at the end of the line. You can have a CAN_IN and CAN_OUT header on each box. At the end of the line, you install your termination on the CAN_OUT header. – user57037 Mar 04 '18 at 22:59
  • Note that if you're using microcontrollers (and not wanting to e.g. interface with a Linux system) you might not need UDP, you can implement your own protocol on top of the Ethernet (physical and/or MAC) layer, and it will work like UDP but simpler. Don't do this if you want to be able to plug it into a normal network. – user253751 Mar 04 '18 at 23:32
  • I did not clarify it in the original question (I edited it now), but the master will be connected to the internet, and I have some security concerns with making the communication bus on IP-based protocols such as TCP and UDP. I could off course make my own protocol directly on top of Ethernet as @immibis mentions, but I think it is a bit out of my league. Furthermore, the boxes and connectors should be water-proof (IP67), so an external header for moving termination as mkeith mentions is a good idea, but not practically feasible for my application (I also added this to the question). – Johan E. T. Mar 05 '18 at 09:27
  • 1
    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". – pjc50 Mar 05 '18 at 10:35
  • 1
    If you have a waterproof cabling solution, you can have a waterproof termination solution, too. – user57037 Mar 06 '18 at 07:54
  • 1
    The termination part is easy to fix. Simply mount a 120R on each node, then connect one end of it to CAN Hi and leave the other side unconnected. Use some external means like a connector + wire, in order to connect the other side of the resistor to CAN Lo. This will not work great for hot plugging though. – Lundin Mar 12 '18 at 13:07
  • CAN is not master-slave, and payload is normally limited to 8 bytes per message, apart from this it may be suitable and offers near-realtime by design. RS-485 with either Modbus (or an own protocol) is master/slave. It is also forgiving about switching termination during operation, telegrams can be long, bitrate quite high on such short distances you have. How much payload bytes need to be transported from how many boxes in total? Are there near-realtime requirements? – datenheim Jan 16 '23 at 07:34
  • @Lundin Or use something like the classic switched TRS connectors which have mechanical switch that is connected when the plug is unplugged to connect the termination. – user1937198 May 16 '23 at 12:19
  • One example of a solution to a similar problem CAN with site reconfigurability thats worth looking at and is typically IP67 rated is NMEA2000/IEC61162: https://en.wikipedia.org/wiki/NMEA_2000 . It uses T-connectors and a manual termination, and runs CAN reliably at 250kb/s with 6m stubs. – user1937198 May 16 '23 at 12:26

3 Answers3

0

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.

pscheidler
  • 1,079
  • 7
  • 13
  • 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. –  Mar 04 '18 at 22:46
  • 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. – pscheidler Mar 04 '18 at 22:56
  • 3
    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. –  Mar 04 '18 at 23:14
0

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.

Jeroen3
  • 21,976
  • 36
  • 73
  • 1
    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. – Lundin Mar 12 '18 at 12:58
  • 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) – user1937198 May 16 '23 at 12:27
0

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.

bobflux
  • 70,433
  • 3
  • 83
  • 203