1
\$\begingroup\$

I'm interested in having an embedded device send data optically. This is for test and measurement, where having conductive cables is problematic since it will perturb the measurement. The device is built as a prototype now except for the data sending interface. The data rate requirements are moderate (10-20Mbps one way). The distance is short, 5-10ft. This is somewhat power limited, but using 0.2-0.5W for comms is okay.

I looked at IrDA but that seems to be almost completely obsolete, and the data rates are too low (other than the very unavailable UFIR/GigaIR). I also looked at TOSLINK, and that seems to be almost-obsolete, and I can't source fast (125Mbps) transceivers, nor can I figure out how to run the slower 10MBps ones reliably at anything close to their max rated speed.

Now, I could hack some kind of completely proprietary UART-over-fiber protocol, or wait for LiFi, or mod some of the really expensive Corning optical USB cables to not have a power conductor... all of these are problematic in various ways. Then I thought, why not just use SFP transceivers on both ends?

I have only a very basic idea of what is inside a SFP, and essentially no idea how to talk to it. Could someone explain to me how to drive a SFP from a microcontroller? Either (a) a UART-over-fiber using SFP and microcontrollers on both ends, or (b) ethernet using SFP from a microcontroller and regular SFP ethernet device on the other end?

P.S. If it matters, the microcontroller is a STM32F446; I would like to stick with STM32 if possible. The device is battery powered from a 2500mAh lithium ion battery.

P.P.S. I can build devices on both sides of the link; the near side would probably have some kind of optical-to-USB-serial converter, if it is not simply ethernet.

\$\endgroup\$
  • 1
    \$\begingroup\$ what about using an opto-isolator ... that way the wires only go near the device, but they do not connect electrically \$\endgroup\$ – jsotola Aug 30 '18 at 3:41
  • \$\begingroup\$ @jsotola It helps a lot, but it's not perfect... having nothing conductive in the vicinity would be better. I may end up having to do that as a fallback. \$\endgroup\$ – Alex I Aug 30 '18 at 3:44
  • \$\begingroup\$ TOSLINK is exactly what you have described. They are obsolescent, but so what, you can get them now, and they are cheap, and the cables are cheap and easy to get. You just drive the led with an hcmos invertor. \$\endgroup\$ – Henry Crun Aug 30 '18 at 6:37
  • 1
    \$\begingroup\$ @HenryCrun Thanks! I had got a pair of TOSLINK transceivers but could never run them at full speed for some reason... I could run them okay at < 1Mbps, high error rate above that. Maybe worth a second look. Do you have a favorite part? \$\endgroup\$ – Alex I Aug 30 '18 at 6:46
  • 1
    \$\begingroup\$ I used toshiba ones rated at 16M sucessfully in the past with 3m cables for 10MHz and 16Mbd data. You must drive LED with push pull cmos - not an open collector transistor drive. Also must have good bypassing and choke filter on RX supply. Lately I have just been using chinese ones at 250k uart, but no idea how fast they will go. \$\endgroup\$ – Henry Crun Aug 30 '18 at 6:52
2
\$\begingroup\$

Looking at what's in the SFP modules, it may not be all that difficult to use them directly.

Since the signals are AC coupled to LVDS, you'll need to communicate in a DC balanced protocol such as Manchester, which your chosen ARM may or may not support (my current favorite Microchip SAME70 does support it). And, of course, add LVDS receiver/transmitters. You may be able to ignore the EEPROM since you only want to work with a single type of SFP module.

Judging by the values shown, you'd probably have to keep the frequency at 10MHz or higher, which you will need to do anyway for that data rate.

May or may not be worth looking into further, but it does look promising to me. Here's an excerpt from the above pdf document:

enter image description here

\$\endgroup\$
  • \$\begingroup\$ Nice! For LVDS conversion, would DS90LV019 or something similar work? \$\endgroup\$ – Alex I Aug 30 '18 at 13:54
  • \$\begingroup\$ Not sure about Manchester, but I can probably do 8b/10b in software with a lookup table. Does the TX expect constant data while it's on? Are there FIFOs or does it send each bit as it gets it? \$\endgroup\$ – Alex I Aug 30 '18 at 13:57
  • \$\begingroup\$ I used SN65LVDS1 last time.. I don't think there's any logic in there, it's almost like an ac-coupled transformer. This is just a guess, I'd get ahold of a couple and do some tests running 5/10/50 MHz through the fiber from a function generator before getting too deep. The Manchester scheme has a training sequence to get things going. You can get eval boards inexpensively if you want to try the M7 Cortex. \$\endgroup\$ – Spehro Pefhany Aug 30 '18 at 14:04
  • \$\begingroup\$ Around page 1140 (yeah, I know) of the datasheet is the description of the UART's Manchester mode. We used one of those modes to get data in a bespoke format through transformers in a special aerospace application. \$\endgroup\$ – Spehro Pefhany Aug 30 '18 at 14:12
2
\$\begingroup\$

SFP Transceivers use high speed differential pairs for transmit/receive on the host side. These generally start at data rates of 1Gbps and go up from there, so they're not trivial to implement and can't just be plugged into an MCU like the STM32F4--such MCUs simply don't have the physical interface for it. It's really the domain of Ethernet switch ASICs and FPGAs.

If you switch to an MCU that includes an Ethernet MAC (there are several options in the STM32F4 family), you could use a conventional PHY with an optical transceiver. TI has a dev board that shows this approach using their TLK105L PHY and a Broadcom AFBR-5803Z Optical transceiver. It appears that design materials are available, but I haven't looked at them. Here's the overview document for the dev board: http://www.ti.com/lit/ug/tidu366/tidu366.pdf. This should not be any more difficult to implement than a regular copper Ethernet interface, which means it still requires a good deal of care, but will be less challenging than a 1G+ SERDES. The downside is that from a quick look at the datasheets this solution will consume nearly 1W, so it likely won't meet your power budget even accounting for the fact that your data rate will be relatively low.

If you want an even simpler option, there are other fiber transceivers beyond TOSLINK ones. Broadcom and Avago would be key brands to look at, but just browsing Mouser's Fiber Optic Transceiver category brings up several promising options in the 50-100Mbd range.

\$\endgroup\$
  • \$\begingroup\$ Avago doesn't exist any more. They changed their name to ... Broadcom (after buying the company previously known as Broadcom). \$\endgroup\$ – The Photon Aug 30 '18 at 4:18
  • 1
    \$\begingroup\$ Also, rather than 1x9, OP might want to look at industrial transmitters and receivers which are designed for lower data rates (DC to 5, 10, or 50 Mbd). \$\endgroup\$ – The Photon Aug 30 '18 at 4:27
  • \$\begingroup\$ @ThePhoton Thanks for the pointer to industrial transmitters/receivers - that sounds exactly like what I was looking for! What do you mean by "1x9" though? I haven't encountered that term before. \$\endgroup\$ – Alex I Aug 30 '18 at 6:03
  • \$\begingroup\$ @ajb Ethernet on the MCU with optical transceiver is def something I thought could work, I just didn't have the right name for it, thanks for the pointer to that reference design! That could work. Hmm, just the AFBR-5803Z is $20+, complete SFP modules can be had for $5-6... I guess probably not many designs use that solution. \$\endgroup\$ – Alex I Aug 30 '18 at 6:15
  • \$\begingroup\$ @ajb "These generally start at data rates of 1Gbps and go up from there" - I suppose that is the most common nowadays, but I thought there are some options for 100Mbps optical ethernet? (not sure if they come in SFP) \$\endgroup\$ – Alex I Aug 30 '18 at 6:18

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.