Topic: Optical link problem

Linking UFX+ with Riedel RN.334.MD, SFP module is Cisco SFP-10G-LRM.
MADI signal from UFX+ to Riedel RN.334. Works fine.
MADI signal from Riedel RN.334 to UFX+, not working. Unless, move the plug away from latching contact at about 7mm. The signal will be fine with UFX+.
Is it the optical power from the SFP transmitter too high that overdrive the receiver on the UFX+?
I changed various length fiber cable, change 50/125 to 62.5/125. All multi mode cable. Try to find optical attenuator but fail as those are single mode.

2

Re: Optical link problem

If you use this SFP for MADI then simply get and insert one that supports the correct specs for MADI. 155 Mbps, 1300 nm, Multimode. Fiddling around with cable attenuators seems like wasted time given the low price of these SFPs.

Regards
Matthias Carstens
RME

Re: Optical link problem

Thank you, clearly the SFP I got supports the speed, wavelength, and multimode. But it seems that the power maybe too high, and there's no power spec with RME MADI i/o. I tried a M32DA, exactly the same, have to minor unplug so that it works.
Which SFP model RME recommend? Is there a power rating spec available from RME?

Re: Optical link problem

Hello 9s,

We've had the same issue with our broadcast systems.

Short version - most audio gear with duplex SC Madi connections use FDDI-compliant transceivers that are frequently overloaded by an SFP, even a 2km multimode short range one.  This is reasonably common but not universal.  As MC mentioned you need an SFP that has compatible light levels.

Long version - Most audio gear using duplex SC Madi connections use FDDI-compliant transceivers, traditionally Avago 5803 or equivalent.  Some audio devices have moved to SFPs which is great, the reason FDDI is still used is compatibility with other Madi audio gear which is fine until you interface something else.

FDDI is an old 155Mb/s local networking optical set of standards that has mostly been replaced by more modern light levels and light budgets.  The receivers on the FDDI transceivers have a rated sensitivity and specific light budget, and the overload point is on the edge of what a commonly available short-range multimode transceiver typically puts out as standard.  Every model of SFP has a different output level and they vary by a few dB between units of the same model.  Our testing indicated our MadiFX receivers would overload around -13dBm or so, varying by unit.  The short-range SFPs we use to feed them were outputting between -12dBm and -10dBm and would usually not work.  Your Cisco SFP+ has a rated TX level between -6.5dBm and 0dBm, so it will never work without significant attenuation.  This model, for instance,
https://www.fs.com/products/23583.html
has the correct nominal specs - 100Mbs, 1300nM, MMF, etc. - but it's TX power is rated between -15dBm and -8dBm, so it -may- work and may not depending on your receiver overload level.

Your best option is to find your optical overload point with an optical meter then find an SFP with sufficiently low output.  100Mbs TX is typically a lower light level than 1Gbs.  However if you need an optical attenuator, yes, they're mostly single-mode.  But that won't matter much in this case, we used them on the inputs to our MadiFX after testing.  Where you will have issues is if, for instance, you have a long multi-mode fiber into a single-mode attenuator into a long multi-mode fiber, then you'll have unexpected attenuation and reflection.  But at 100Mbs with the attenuator close to the receiver you'll have predictable attenuation and some but not harmful reflection.

Good luck,
Hugh

Re: Optical link problem

Hugh wrote:

Hello 9s,

We've had the same issue with our broadcast systems.

Hugh

Thanks Hugh, your info provide great help, now I know which spec I shall go for.

6

Re: Optical link problem

Hugh is right. Multimode SFP modules at 155 Mbps typically have -14 to -8 dBm TX output power as Single mode (SFP), and -18 to -14 dBm as Multi mode (MFP) version. Higher specced (=newer) SFP modules seem to have more output power. I wasn't aware that this can cause complete failing, though.

Regards
Matthias Carstens
RME