Hacker News Reader

Comment by crote | Hacker News Reader

I'm surprised it works this well!

A while ago I looked into this for a similar-ish hobby project, and the main dealbreaker seemed to be the mandatory AC coupling capacitors: they are intended to block DC currents, so a signal which is substantially slower than intended is essentially fighting a high-pass filter. This is also why there are special AV SPF transceivers: Unlike Ethernet, SDI suffers from "pathological patterns" consisting of extremely long runs of 1s or 0s, which can cause "DC wander" [0]. SDI transceivers need to take this (albeit extremely unlikely) possibility into account, or risk losing signal lock.

For this reason I pretty much gave up on the idea of reliably going sub-100Mbps on cheap and easily available 1G / 10G SFP modules. Seeing it (mostly) work for TOSLINK at 3Mbps is beyond my wildest expectations - I bet the LVDS driver's high slew rate is doing quite a bit of work here too.

[0]: https://www.ti.com/lit/an/snaa417/snaa417.pdf

View on HN

The article mentions S/PDIF (which TOSLINK is an optical version of) uses Manchester code[1] which eliminates the DC component by ensuring every bit has at least one transistion of the signal between high and low.

[1] https://en.wikipedia.org/wiki/Manchester_code

Yup, but that only works if those transitions happen frequently enough compared to the time constant of the high-pass filter. Presumably, that's why the author found that the optics only worked with signals above about 150kHz.

The problem is the speed. S/PDIF doesn't have a DC component at the S/PDIF bit rate, but to an SFP+ transceiver that S/PDIF signal is a lot closer to DC than to its expected signal. A single S/PDIF bit viewed as if it were a 10Gbps signal looks like thousands of 1s followed by thousands of 0s. Yes, they all balance out in the end, but you can still develop quite a large drift within a single sub-S/PDIF-bit sequence.

A thought experiment to clarify it: let's say you are hoisting a bucket with a DC motor. You're feeding it with a 50Hz AC power source. It's obviously not going anywhere, because it's just oscillating rapidly. You'd need for the motor to run in a single direction for a few minutes to actually lift the bucket. Now drive it with a 0.0000001Hz AC power source (which starts at peak voltage). The motor is going to reverse after 58 days, but does that actually matter? For any practical purposes, how is it different from a DC power source?

Thanks for the explanation!

Does SFP+ not have a scrambler/descrambler to make this a non issue, like almost all other phy?

https://en.m.wikipedia.org/wiki/Scrambler

This is done before the SFP+ module sees the signal, but the module makes the design assumption that it is being done. It is right for 10G ethernet, it is wrong (at a certain time scale) for SPDIF.

I also think that https://en.wikipedia.org/wiki/Line_code is the term you're looking for.

Ahh, I'm only familiar with the copper side of things. But, that explains why the search came up with nothing for SFP+!

> I also think that https://en.wikipedia.org/wiki/Line_code is the term you're looking for.

In 10G ethernet phy's, it's a multiplicative (self-synchronizing) scramblers [1] and does not use line code. From what I remember, it's statistically fine, and plays into LDPC correction easier.

[1] https://www.iol.unh.edu/sites/default/files/knowledgebase/10...

That's why you get problems around 10Gbps, but simple 10Gbps optics and afaik all 1Gbps or slower optics don't use the "fancy" kind of signal processing because it wasn't needed. Their lower cut-off frequency should be around 100kHz.

I can understand DC wander being a problem on copper ethernet, where the signal goes through an isolation transformer - which is there specifically to block DC; you don't want to accidentally make a ground loop between buildings after all.

But presumably an optical SFP doesn't need to block DC, because you can't make a ground loop over optical fibre?

Reply on news.ycombinator.com