Driving An SFP Module with Protocols Other Than Ethernet

[ajb]

Using SPI instead of UART could be more flexible.  Some MCUs directly support word oddball SPI word sizes, including some STM32s, and a 256x2 byte lookup table of pre-encoded 10-bit words wouldn't be too bad.  It's a little bit of memory overhead to trade against transmission overhead on the wire verses an 8->16 bit encoding (or 8->18 by the time you account for UART start/stop bits ). 

Using a little greenpak device for encoding/decoding could be worth exploring as well--could be neat to build a dumb but very flexible adapter module that way. 

[David Hess]

I'm pretty sure we did something at work a few years back where we got DC equalisation on UART at low processing overhead by repeating every byte inverted, but I can't remember how we avoided DC from the start and stop bits. Obviously it's inefficient, but when the channel is wide enough it doesn't matter. Gave us some redundancy for free too.

As long as you're sending continuously with no gaps, the start and stop bits will cancel each other out

I just noticed that; the start and stop bits have opposite polarity because the stop bit sets up detection of the edge of the following start bit.  All that is required now is continuous transmission to prevent a stop bit which is longer than one bit duration, and DC balancing of the 8 data bits.

If 8 (actually 9) zeros or ones in a row cannot be tolerated, then the data can be split into nibbles and odd or even bits used to maintain DC balance over 2 bit periods.  This could conceivably be Manchester encoding of 4 data bits into 8 RS-232 bits with start and stop bits for asynchronous operation rather than regenerating the clock from the Manchester encoding.  I guess that leaves one of the unused codes as an idle code, but now DC balance has to be over 4 bit periods but maybe that is acceptable.  The more complex this gets, the more 8b10b encoding becomes reasonable.

[jbb]

Next step; using Ethernet

[Nominal Animal]

Next step; using Ethernet

In a different thread, I mentioned that one could use raw Ethernet frames (layer 1 frames) to transmit RS-232 data between endpoints if using a small FPGA (with a sufficient SERDES), making it routable within a single local area network segment using standard switches.  You could even wrap the data within UDP/IP frames with configurable source and destination IP addresses and UDP port numbers, making the traffic ordinary UDP/IP.

The point there was, wrapping the datagrams in an Ethernet frame does not actually cost that much; you definitely don't need a full IP stack at all.  Only the 32-bit checksum (0x82608EDB, x³²+x²⁶+x²³+x²²+x¹⁶+x¹²+x¹¹+x¹⁰+x⁸+x⁷+x⁵+x⁴+x²+x+1) at the end (but before the interpacket gap) needs computation.

To drive the SFP module, one could use e.g. Microchip LAN9250 Ethernet controller (7€ to 9€ in singles at Mouser), communicating with it via 8 or 16-bit data bus and SPI from basically any microcontroller.

I do realize OP asked explicitly about other than Ethernet, but my point is that you can easily offload or use Ethernet on the wire, without specifically targeting Ethernet in your MCU.  If you look at the Microchip EVB-LAN9250 SFP interface (FTLF1217P2 on page 6), you only need four pull-up resistors (2×82Ω + 2×49.9Ω), two pull-down resistors (2×130Ω), four 100nF capacitors in series with the four data lines, plus some 3.3V supply filtering and mode strap resistors for the SFP module that will depend on the exact SFP module used.  In particular, one might use a separate slave microcontroller between the main microcontroller/device and the LAN9250 chip, converting the data from/to the custom format or data stream, to Ethernet packets; a kind of a custom-protocol to Ethernet + SFP driver module.  Replacing that module you can switch to a different interconnect, without chaning the main data stream format at all.

TL;DR: Having your main device know nothing about Ethernet or the interconnect used, it would only cost about 20€ in parts in singles from Mouser to implement an Ethernet-over-SFP interconnect using 100Base-FX (like the Broadcom AFBR-57E6APZ-HT SFP module OP linked to), if you use a translating/buffering microcontroller and e.g. LAN9250 industrial 100Base-FX ethernet controller.  To switch to a different interconnect fabric, you just replace the microcontroller + LAN9250 + SFP module, with no changes to the original device, maximizing upgrade path and long-term maintenance opportunities.

[Echo88]

Going with a suitable 100BASE-FX controller would of course be the most cost effective way to go for direct SFP ethernet usage and id go that way if there were arduino libraries that would use the LAN9XXX transceivers.
In my case id like to use the existing arduino ethernet libraríes which use e.g. a W5500 (or ESP32 + LAN8720) and just add a medium converter IC to get SFP connection.
However, im unsure if i can connect the medium converters ethernet input pins directly to the W5500 output or if the underlying 100BASE-TX stuff like baseline wander correction necessitates a magnetics path? The RTL8213B datasheet is rather sparse on specs.
I attached a schematic showing the intended connection scheme USB -> CP2102N -> ESP32 -> W5500 -> RTL8213B -> SFP.
Any thoughts?

[Echo88]

Attached is an alternative version doing what was intended by OP in the first place: using SFP modules without resorting to Ethernet.
It uses the already mentioned FSK-modulation idea and should be suitable to achieve <=1MBit (yet untested).
Since this is my first time using the 74HCT4046A it would be nice if more experienced users could point to obvious errors in the schematic or add improvements, before i produce a pcb to test it.

Thanks.

[fisafisa]

Open hardware project using sfp with custom protocol : hotrio

https://conferences.iaea.org/event/450/contributions/40904/attachments/23675/41361/2-20260520%20-%20HotRIO%20Experience.pdf
https://vcis.f4e.europa.eu/hotrio-hardware/html/index.html
https://vcis-gitlab.f4e.europa.eu/electronics/hotrio
https://vcis-gitlab.f4e.europa.eu/electronics/hotrio-software

[ksjh]

It might be interesting to view this video from the C38C3 CCC congress: https://media.ccc.de/v/38c3-going-long-sending-weird-signals-over-long-haul-optical-networks
Ben Cartwright-Cox has also been trying to send "weird" signals over fiber and discussed the different hurdles when using SFP modules.

[Doctorandus_P]

A little bit different, but still related is this video from The Signal Path:

TSP #309 - Mysteries of Optical HDMI Cables - Tutorial, Teardown & Analysis of Inexpensive Optics

 

[Amper]

Just to ad some of my findings, i started a thread quite a while ago talking about uart via SFP and it ended up toxic like most longer threads, never visited it again and cant find it rn xP

Today with a bit of claude help i finally got it to work nicely, 1-2 kinks still to be worked out but maybe this helps some people:

Most sfp modules can handle frequencies as low as 40kHz with not much issue, actual issues as identified before are the long time it takes for the amplifiers in the sfp to settle after a period of dark and the need for a DC free signal.
This prevents plain uart from working reliable, you have to keep the link awake all the time to not have several .1s of garbage before bytes are valid and you have to manchester encode.

The attempt i did a few years ago didnt work well (skill issue on my part) but since i have quite some experience with the problems i kicked claude into building me a good solution.

my hardware is based on open source sfp breakouts (https://osmocom.org/projects/misc-hardware/wiki/Sfp-experimenter). I added an stm32L412 to the layout, a debug led and an oled (currently unused), uart 2 reads in an external uart stream, the controller then puts it into frames byte by byte and sends it via 2MBaud uart1 to the sfp. The other side takes the stream apart again after synchronizing to it (manchester sucks hard when combined with a constantly allive bitstream, you cant find the beginning of frames easily, thats what broke me back with my manual tries) and puts it out via its own uart2. I also send some bytes on every frame for IO expansion and other stuff but thats kinda trivial once the link is stable.

One important drawback about this entire thing is the fact that the uarts handling the external communication of cause run at the same baud. This is fine as long as there is signifficant pauses between telegrams (like in my video with nema gps signal) but when continuously transmitting any small difference between the bauds leads to inevitable buffer filling, at some point one has to overflow and the link breaks. Thats ok for some applications but not for all, just keep it in mind, it will never (mathematically impossible in this topology) be an exact replica of any input stream, there always is limits.

One idea i had to mitigate this is to go the full hardware route, build essentially a small fsk or fm transmitter at something like 1GHz (or 433MHz???) and decode it on the other side. This way the carrier never stops and you can even use it to move DC via the sfp with very few limitations. maybe some day...


https://youtube.com/watch?v=9dIxWYnfbqY