Ethernet to Fiber media converters

Yep I mentioned that above, so my gigabit router supports 10/100/1000, which is why this works

These are definitely staying

Yeah they are picky units. They demand a solid gigabit connection or else they just won’t work. Not just TPlink but all of them. Here’s a very nice gigabit FMC from Ubiquiti:

Can be powered by an PoE port on a switch. Saves needing another supply.

That one says “10/100 Mbps Ethernet are not supported” on the datasheet.

So if your DAC’s network card only supports 10/100 that won’t work either right?

Like you said earlier, some people have been caught out with buying the wrong FMC’s for their DAC’s network card (or their router)

Yeah everything must be gigabit. That’s the unit I recommend to my clients for connecting to my Superstream streamer. Besides being able to be powered by PoE, it has a PoE passthrough to power one of these very nice wifi units. Great for adding wifi for Roon remote control and fiber to a simple gigabit PoE switch. I use these PoE wifi units:

https://unifi-mesh.ubnt.com/#home

The F-PoE and UniFi mesh units can neatly mount to the wall behind the equipment rack. Both powered by the Ethernet cable.

1 Like

Nice.

I am seriously liking the addition of these FMC’s, right from the get go.

Common sense tells me I don’t need two LPS-1’s but I don’t want to change anything lol

I switched the FMC’s around to test this and get the same thing - the router-side FMC’s LPS-1 runs noticeably warmer than the DAC-side FMC.

And after previously switching the LPS-1’s around before, I have no idea why the router side FMC is always drawing more current.

Playback has been flawless, no connection issues, all LED’s indicators are as they should be.

Not that it matters much though. Just an interesting observation I guess.

These are really great additions

Thanks for pointing me to this thread @dabassgoesboomboom. As you know, I already purchased two gigabit FMCs, but they won’t work with my network DAC which I now know is only 10/100. I guess I should probably return them to Amazon and pick up two MC110CSs like you’ve been using. Is there a relevant difference between the MC100CM and the MC110CS? Comparing the two models on TP Link’s website shows only a differences are (a) transmitting and receiving data at 850nm vs 1310nm (don’t even know what that means), and (b) how far they can extend (1.2 miles vs 12.4 miles). For whatever reason, the MC110CS is about $6 cheaper than MC100CM on Amazon right now.

I had purchased the Tripp Lite Duplex Multimode 62.5/125 Fiber Patch Cable (SC/SC) for my gigabit FMCs. Is there a different cable that goes with the 10/100 FMCs? Would you be so kind as to advise me on what to buy?

Finally, does it matter that in between my gigabit router and the first of the two FMCs, I have a gigabit switch (NetGear GS105)? I would think there is no need to put a 10/100 switch in place.

I really really appreciate your help! :fist_left:

Hey Brice

You do need to make sure you have the right fiber cable for the right FMC as @wklie mentioned - perhaps if you get the MC100CM you should be able to use your existing fiber cables. Double check this. Or you can just copy exactly what I have working reliably - see below.

No problems here, there’s a good chance your gigabit router supports all 10/100/1000 connection speeds so you should be fine with the 10/100 model FMC. You can double check your router for this too to be certain but it seems a safe bet.

If you want a combination that works you can just copy me, otherwise you need to check carefully to make sure you’re getting the right cables for the right FMC’s:

  • 2 x MC110CS
  • 1 x SC-SC Duplex 9/125µm Corning ClearCurve Single Mode Fiber Optic Patch Cable (whatever length you want)

https://www.fiberoptics4sale.com/products/d3yys3fiscz?variant=51584803349

As Peter suggested (and I agree), try and power your DEQX side FMC with a linear PSU if you can… Just use the stock suppled PSU for the router side (or switch side) FMC

Apologies I don’t have time to relook at all the FMC models (it’s been a while) but I hope the above helps - I know it works so that’s a good start at least.

1 Like

@Brice_Lang get one unit of this $11 power supply as well:
https://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?search_type=jamecoall&catalogId=10001&freeText=1953639&langId=-1&productId=1953639&storeId=10001&ddkey=http:StoreCatalogDrillDownView

1 Like

Good point if you’re in the US. These Jameco linear PSU’s aren’t available here in Oz sadly or I’d have a few of them.

I haven’t tried fiber, so cannot corroborate the comparisons personally. While I was reading comparisons of several people that have tried direct bridged ethernet connection between the computer and endpoint along with FMC, they all liked the sound without the fiber in the middle. Just straight copper ethernet connection.

I have tried it on 2 of my Macbook Pros so far. It’s worth a shot.

Hey zoom25. I know the CA Forum thread you are speaking of where all these observations were made. The funny thing is a large group gravitated towards FMC’s - then many gravitated to having a networked endpoint with the direct ethernet (bridge) connection you mentioned and said this was better than FMC’s… then it went full circle with many saying the direct USB connect sounds best. Now it seems the SOtM trifecta solution thing is what a few have moved to.

I’ve spoken to a couple clever people about why some didn’t like the SQ of FMC’s and these clever people had some general ideas.

Disclaimer: it’s a guess - nobody has any idea about what’s actually happening with absolute certainty. Also it has nothing to do with loss of bits, so in case someone jumps in with stories about how data centres work fine and you can stream music from Norway to Australia and the bits are all there - yes, this has nothing to do with dropped bits. Assume bit perfect playback.

Ok so the thinking is that the ethernet-to-optical-to-ethernet conversion process results in increased levels of jitter and greater number of re-tries with the ‘receiving end’. If the receiver FMC is directly connected to your networked DAC, they tell me it’s POSSIBLE (or not) that the DAC’s internal network card is working harder with these re-tries (yes, it’s still bit perfect, not talking about dropped bits at all) and this extra work is creating noise within the DAC and affecting SQ…

If the FMC is connected to a networked microRendu (or whatever, just an example), which is between the DAC and receiver FMC, well the microRendu is doing ‘the extra work’ and not the network card inside the DAC. But it still MAY (or not) affect SQ.

No such thing as a free lunch in this hobby though. So when adding FMC’s you are also adding more PSU’s to the chain/system too. These may (or not) affect SQ in different ways.

6 days of the week I just have a microRendu powered by mains connected linear PSU’s connected to my DAC/s because it’s quick and easy to get music playing fast. But sometimes on the weekend when I want to go full throttle bonkers in tinkering mode, I take out my modified FMC’s (switching regulators replaced with low noise linear regs) and I power them with 5Vdc power banks, keeping them completely off mains power… The isolation from mains power seems (to my ears) to be a bigger/more important factor than the voltage noise/ripple output of the powerbanks powering the FMC’s (plus I have low noise linear regs to deal with that anyway) - completely breaking/isolating leakage current loops (battery powering the FMC’s and the optical isolation) perhaps seems to be the bigger factor?.. who knows. It sounds incredible to my ears though, very noticeable but not practical for everyday use for me.

1 Like

Did anybody report that they found the number of retries actually increase with FMC? In a simple home network with proper Ethernet cable retries should be rare. I’d be surprised if FMC increases that.

1 Like

Just had a look at one of my Roon endpoints, the one tiny my main listening room
It’s been connected via an FMC the last day with Roon playing many hours.
The connection is
Roon Core -> 10GEth Switch -> 1GEth Netgear GS110 TP with SFP -> TP-LINK MC220L -> Roon Bridge

All except the Roon Bridge have been up more than 30 days.
None of the devices where I can check have had any packet loss in layer 2.

Just curious as I also own a GS110TP… what model 10gbe switch are you using?

I have two Netgear GS110EMX and 2 Asus XG-U2008.
My home network is a tiny bit more complex than the description above. :slight_smile:

Yes, as mentioned this is what these experts told me (in private) and they THINK it’s due to the ethernet to optical to ethernet conversion process. If not retries they think it could be a signal integrity and/or jitter/phase noise thing where the same thinking applies - if the FMC is directly connected to a DAC internal card, the latter is working harder - again due to the optical conversion process.

I have to re-emphasise again if it wasn’t clear - nobody is reporting anything as fact. Just guessing what the technical mechanisms could be, to explain some people’s observations.

You won’t find me disagreeing/arguing with a network engineer (you) :slight_smile:

I’m not an expert but I do ask the experts and sometimes they disagree among themselves - that’s OK too.

Do you have any theories? Increased jitter due to optical conversion, creating ‘more work’ inside the DAC? SI?

When discussing retries (not dropped bits) do you mean packet loss or frame loss?

Also, if we pretend for a small moment that adding stock standard non-audiophile FMC’s directly before a networked DAC does cause the DAC’s internal network card to work a little harder (and assume we don’t know the exact mechanisms)… the bigger picture thing is some networked DACs will design for/around this better than others, with better isolation internally of the network card, maybe EM/RFI shielding internally too. So this will be a factor in different people’s experiences when adding FMC’s.

Just in case anyone reading this thinks I’m making any huge sweeping generalisations.

But we are in the tinkering section here, so all crazy theories are welcome.

There were (and still are) no packets dropped (& no packets with errors) in layer 2.
This implicitly means there were no retries.