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.

  • 1
    \$\begingroup\$ you are right about using ethernet for this application, but don't cut corners. it's not too difficult to have a microcontroller that will simply take UDP/IP packets and toggle gpio. even take a second rapbery pi, it's probably cheaper then developing a new board. \$\endgroup\$
    – user76844
    Commented Apr 30, 2021 at 23:57
  • \$\begingroup\$ This TI AppNote might be of interest: Hundreds of Megabits @ Hundreds of Meters: Extending the Transmission Length for LVDS \$\endgroup\$
    – brhans
    Commented Apr 30, 2021 at 23:59
  • \$\begingroup\$ Sub-microsecond latency and Ethernet is not possible. Smallest Ethernet packet is multiple bytes so even at gigabit speed that's multiple microseconds and with overhead that causes non-deterministic behaviour. Unless you would care to specify what exactly you mean with "Ethernet hardware here". Do you mean cabling, connectors, other hardware? \$\endgroup\$
    – Justme
    Commented May 1, 2021 at 0:05
  • \$\begingroup\$ Can it be done? Yes. Would I recommend it? No. Ethernet is a heavy-weight solution for reading/writing remote GPIO pins. If you want to go that route, Raspberry Pi is the solution. But "something" over RS485, such as CAN, Modbus, or (I2C over RS485) will be much simpler. RS485 is industry standard for remote bit-banging, and is quite reliable. If you love Cat-5/6 cabling, you are welcome to use it. If you need galvanic isolation, that can be arranged. Need some power? That can be added. \$\endgroup\$ Commented May 1, 2021 at 0:50
  • \$\begingroup\$ EtherCAT IO modules process packets "on the wire" and theoretically 15us response is possible, but 1ms is more typical. Very deterministic, if desired (includes synchronization mechanism) , is simple for master to control (specialty crafted ethernet frame). \$\endgroup\$
    – crasic
    Commented May 1, 2021 at 0:58

4 Answers 4


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.

  • \$\begingroup\$ I like this answer as it is the only one in the spirit of the question imo. Not about ethernet but about how to get data somewhere 30m away. Maybe it will be even easier to skip all the transformers and manchester's and use STP with DC coupling? I don't know the chances of this working and it is also less safe. \$\endgroup\$
    – tobalt
    Commented May 1, 2021 at 21:58
  • \$\begingroup\$ The galvanic isolation is a huge benefit when working at distance. Manchester coding is ridiculously simple, biphase-mark only slightly more complex. One possible hack would be to use I2S from the R.pi and send it via AES/EBU. That’s about 6Mbit right there, and would have a deterministic latency of about 4-5us using 192kHz mode. \$\endgroup\$ Commented May 1, 2021 at 22:26
  • \$\begingroup\$ Thank you all for your responses - a lot of good information. I think this answer is probably closest to my original intention. Thinking an SPI-type interface may manage the throughput on 4 wire (pairs), "just" add Manchester encoding, LVDS drivers, ac-coupling capacitors and 100Mbps magnetics (I know that's an oversimplification). Hacking Ethernet/PoE just sounds enticing: reasonable isolation, remote power, simple cabling. But perhaps distributed "brains" like Pi Picos with conventional ethernet may make more sense (to control a motor via quadrature where occasional bit errors add up). \$\endgroup\$
    – M Szil
    Commented May 3, 2021 at 10:24

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.


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'


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.


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.