Is it possible (with reasonable effort) to use ethernet hardware to provide point-to-point digital I/O bridge?

Question

I'm interested in designing a "simple" circuit that would bridge digital inputs or outputs over a distance with relatively low latency. The idea is to take several pins from a GPIO bus like Arduino or Raspberry Pi and reproduce their status remotely - let's say 8-bits in each direction, rather than freely configurable, and up to 30m distance and shoot for <1us latency (ideally no overhead that could cause non-deterministic behavior).

I like the idea of trying to leverage ethernet hardware to provide decent noise immunity, cheap standard cabling, and the possibility of providing remote power. The devices I find (and older questions on stack exchange) seem to always circle back to a fairly complex packet exchange and highly integrated ICs (or is that "highly ICs"). Most industrial solutions (e.g. Modbus or profinet) also stick to the packet model. I'd be happy to just use a clock and some 74-series shift registers, etc. to generate a serial train and decode it on the other end - just wondering if there's a "middle-bit" that would manage the level shifting and signal processing without getting into all the more complex ethernet layers (I suppose there may be some clock recovery - although I'd be happy to use part of the cable for a clock signal, or force the serial speed to be a standard ethernet speed and a start/stop bit if needed). I don't care about running through standard ethernet hardware (switches, etc. - those would all tend to introduce significant latencies), but would like to preserve the magnetics to obtain better isolation and power injection.

Thanks for any suggestions or references to existing hardware solutions or perhaps better suited protocols.

Answer 1

Without thinking on it too much:

• Send the data as UART-style encoding, with a start/stop bit (maybe from the UART itself)
• encode/decode these UART-style byte-frames using Manchester coding
• transformer-couple as normal for Ethernet over UTP

The issue with LVDS or RS-422 is that, by themselves, they don't define a DC-free code. So they don't work so well with transformers and other AC coupling techniques like those used with UTP.

That's why I suggest Manchester coding. It's what's used for 10Mbit Ethernet. It's fairly simple and yields a DC-free code. It’s feasible to use TTL or a small CPLD to implement it.

An improved version of Manchester uses differential coding. This avoids a number of issues, including idle all-0 / all-1 locking and polarity swap. Differential Manchester is also known as biphase-mark coding. It’s the protocol used for SPDIF / AES audio.

More here: What is the advantage of differential Manchester

It could also be possible to use an Ethernet PHY chip and make a logic bridge that converts signals to an appropriate MAC stream (MII, RMII), but I think the whole link partner establishment stuff begins to drag the 802.3 camel’s nose into the tent.

Answer 2

EtherCAT IO modules are off the shelf industrial devices that process packets "on the wire" and theoretically 15us control cycle is possible, but 1ms is more typical.

EtherCAT slaves process packets "on the wire" without an application stack to delay or add jitter. Latency, depending on the definition could be sub 1us, more complex devices might have a microcontroller that would add latency, but IO devices are able to be run directly out of the basic controller without supporting hardware.

They are designed to be used with PLCs using the protocol, but any device with an ethernet port can serve the role of master.

The protocol is deterministic, there are incrementing modes of synchronization through the built in synchronization mechanisms, . It is simple for master to control and needs only a specialty crafted ethernet frame.

You can roll your own IO module (slave) with an EtherCAT slave controller IC, available from a number of vendors. In basic IO mode, very little is required beyond an ethernet phy or two to implement.

Other variants are available (fiber, gigabit, poe)

Example applications include large factory robotics where servo time synchronization in 3 axis*6 limbs is safety and process critical.

Full Disclosure: I develop and manage commercial specifications for EtherCAT in my industry, and EtherCAT technology group (ETG) makes money selling access to these proprietary specifications, similar to USB.

Answer 3

On the surface, it sounds reasonable. Dig a little deeper and some challenges emerge:

1. error tolerance. You have a cable running 30m - that's a big antenna. Lightning might induce errors. How do you propose to manage errors? Ignore it as another transmission is going to replace it in a microsecond?

2. custom hardware to implement the protocol might just be more effort than just going with the 'standard' ie ethernet solution. Many chips have just about everything built in.

If all you're doing is driving leds displays or similar, error management is probably low on the priority list - you'll get some garbage but it will fix itself. If you're wanting to do some sort of control where errors might cause an issue or safety problem, then you might want to rethink your strategy.

If you do care about errors, then you'll need to add redundancy - ie extra bits to your message. That means sending a packet of data. It could mean the overhead exceeds your payload - maybe you want to send 16,32 etc bits to even the score?

These days, hardware wise, it is not unreasonable to have distributed processing - a single chip micro has a slab or ram, flash and cpu along with an ethernet interface. Download the code via the network and have it run the time critical i/o and use the network with it's latencies etc to get/put the data. Run micropython etc on these nodes. There's ethernet time protocol that can achieve sub-microsecond timing alignment so multiple nodes can output the data 'in sync'

Answer 4

100 base T runs at 25Megabaud, and signals propogate at about 200m per microsecond so "Fast Ethernet" hardware is fast enough to meet your requirements.

You'll need SERDES (serialising and deserialisng) at each end. It sounds like a good application for a small FPGA. but yeah you could use 74-series logic if you want to be like Ben Eater I guess.