• Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Fiberoptic Ethernet and bits on the wire

Conversely with copper ethernet, common mode noise might get in and interfere ... thats a ground loop. Hospitals use ethernet isolators because ground loops/common mode noise can cause safety issues when an electrode is in the heart ... that is to say, the electronics are there
??? Copper ethernet is transformer balanced and isolated in and out of routers.

From:https://www.skyworksinc.com/-/media...nderstanding-the-ieee-8023bt-poe-standard.pdf

"Ethernet is an isolated network, so each twisted pair connects to a data transformer. PoE
simply injects a DC voltage (~54 V) onto the twisted pairs of the Ethernet cable through center taps on the data
transformers."

Edit: Looks like im late to the party.
 
??? Copper ethernet is transformer balanced and isolated in and out of routers.

From:https://www.skyworksinc.com/-/media...nderstanding-the-ieee-8023bt-poe-standard.pdf

"Ethernet is an isolated network, so each twisted pair connects to a data transformer. PoE
simply injects a DC voltage (~54 V) onto the twisted pairs of the Ethernet cable through center taps on the data
transformers."

Edit: Looks like im late to the party.
I will add that for audio, you don’t need Cat8 cables, so if you stick with Cat5 or 6 UTP (Unshielded Twisted Pair), the connectors are also plastic. Between the UTP cable and plastic connectors you have isolated the chassis grounds - so no possibility for a ground loop.
 
I guess a non-audible impact is expected, but in practice, don't the audio data packets get buffered again at least once or twice before an analog signal is rendered?
Forget buffered, it needs to get decoded or reorganized.
 
??? Copper ethernet is transformer balanced and isolated in and out of routers.

From:https://www.skyworksinc.com/-/media...nderstanding-the-ieee-8023bt-poe-standard.pdf

"Ethernet is an isolated network, so each twisted pair connects to a data transformer. PoE
simply injects a DC voltage (~54 V) onto the twisted pairs of the Ethernet cable through center taps on the data
transformers."

Edit: Looks like im late to the party.
Lots of mentions of PoE... does any of you use it in their home network? I know why it's convenient in some places, but not sure why I'd use it at home... And I am not sure why anyone would think it could pose challenges that another device with a $1 wall wart doesn't...
 
Last edited:
??? Copper ethernet is transformer balanced and isolated in and out of routers.

From:https://www.skyworksinc.com/-/media...nderstanding-the-ieee-8023bt-poe-standard.pdf

"Ethernet is an isolated network, so each twisted pair connects to a data transformer. PoE
simply injects a DC voltage (~54 V) onto the twisted pairs of the Ethernet cable through center taps on the data
transformers."

Edit: Looks like im late to the party.
I will add that for audio, you don’t need Cat8 cables, so if you stick with Cat5 or 6 UTP (Unshielded Twisted Pair), the connectors are also plastic. Between the UTP cable and plastic connectors you have isolated the chassis grounds - so no possibility for a ground loop.
First of all copper ethernet works. The transformers in the phy block low frequency current and pass higher frequency. Ground loops are not only 0Hz or DC voltage so, no, higher frequency common mode noise most definitely passes through the PHY. I'm not here to sell anything but anyone who has dealt with either audio ground loops or has been in a lab environment may have had problems with ground loops. If you never have, then great. Yes using UTP and plastic connecters goes a long way toward preventing low frequency loops. The impedance of ethernet transformers simply isn't infinite but the impedance of fiberoptic glass (essentially) is.
 
Lots of mentions of PoE... does any of you use it in their home network? I know why it's convenient in some places, but not sure why I'd use it at home... And I am not sure why anyone would think it could pose challenges that another device with a $1 wall wart doesn't...
We do. Our Netgear router connects to half a dozen Netgear WAX218 WiFi access points throughout the house. The access points are all mounted in ceilings, so we use POE to make the installations simpler and tidier. Works great.
 
First of all copper ethernet works. The transformers in the phy block low frequency current and pass higher frequency. Ground loops are not only 0Hz or DC voltage so, no, higher frequency common mode noise most definitely passes through the PHY.
The transformers still provide 30-50dB of attenuation to that higher frequency common mode noise.

Also PoE, has zero impact on the noise reducing capability of the switch which is typically 30-50dB via transformer isolation. PoE flows through the centre tap of the transformer resulting in equal current in both halves of the winding. The result - DC bias cancellation and no impact to the transformer’s ability to attenuate noise.


Yes using UTP and plastic connecters goes a long way toward preventing low frequency loops. The impedance of ethernet transformers simply isn't infinite but the impedance of fiberoptic glass (essentially) is.
The problem you face is if noise was an issue, why is there never evidence of this in this forum or any forum/web page?
Let me illustrate - using text as that is visual. My text here is completely readable because this is what the bit pattern looks like for this word:

01110111 01101111 01110010 01100100

If noise toggled one of those bit, let’s say the first bit, it would become:

11110111 01101111 01110010 01100100

and the ascii for that would be:

÷ord

Clearly not what I typed.

Why you never see that type of error on ethernet is because ethernet's cyclic redundancy check would find that packet in error and toss it, TCP would then request a resend and the text would now be correct and displayed as I typed it.

I am using this text example to make it plainly clear how this works. Audio that uses TCP works exactly the same way. If a bit was flipped in an audio packet, ethernet’s CRC32 would detect and toss the packet, TCP would request a retransmission and the packet is resent and the audio would be delivered in bit perfect form.
 
Lots of mentions of PoE... does any of you use it in their home network? I know why it's convenient in some places, but not sure why I'd use it at home... And I am not sure why anyone would think it could pose challenges that another device with a $1 wall wart doesn't...
PoE is a red herring here, I know of only a few audio devices that use PoE, most don’t. So if your audio device is not PoE, then PoE is not an issue and merely a distraction in the discussion. If it is PoE capable, I already covered why it’s a non-issue too.
 
Let me illustrate - using text as that is visual. My text here is completely readable because this is what the bit pattern looks like for this word:

01110111 01101111 01110010 01100100

If noise toggled one of those bit, let’s say the first bit, it would become:

11110111 01101111 01110010 01100100

and the ascii for that would be:

÷ord

Clearly not what I typed.

Yeah so we aren't talking about flipping bits here rather common mode noise/broad spectrum ground loops entering the DAC and directly affecting perhaps the analog output stage. I have dealt with ground loops as have many people doing audio. Professional studios and labs mitigate ground loops/hum. Its a thing.
Why you never see that type of error on ethernet is because ethernet's cyclic redundancy check would find that packet in error and toss it, TCP would then request a resend and the text would now be correct and displayed as I typed it.

I am using this text example to make it plainly clear how this works. Audio that uses TCP works exactly the same way. If a bit was flipped in an audio packet, ethernet’s CRC32 would detect and toss the packet, TCP would request a retransmission and the packet is resent and the audio would be delivered in bit perfect form.
Yeah we are talking about two entirely different things.... bits are bits ... I am discussing common mode noise that travels over electrical connections regardless of the bits ... if you don't have a common mode noise problem its a non-issue for you. The first time I encountered it was a new HDMI cable on a new video card that was causing a massive hum on my studio monitors ... there was no direct connection, rather RFI ... RFI is common mode and doesn't pass over fiber
 
Last edited:
Yeah so we aren't talking about flipping bits here rather common mode noise/broad spectrum ground loops entering the DAC and directly affecting perhaps the analog output stage. I have dealt with ground loops as have many people doing audio. Professional studios and labs mitigate ground loops/hum. Its a thing.

Yeah we are talking about two entirely different things.... bits are bits ... I am discussing common mode noise that travels over electrical connections regardless of the bits ... if you don't have a common mode noise problem its a non-issue for you. The first time I encountered it was a new HDMI cable on a new video card that was causing a massive hum on my studio monitors ...
VERY unlikely for bit errors to occur, digital tranmission is pretty iron proof if you stay within spec.
But also that's why a streaming service like Spotify uses TCP/IP...it doesn't matter, TCP will retransmit with zero impact to the app. TCP tests the reliable needed transfer rate by opening the transmission window until it arrives at the overall best balance needed [1]... but you can also implement other protocol stacks that work equally well. QUIC over RTP is just as good in the real world. Bandwidth is seldom an issue these days unless you're doing large scale app stuff.

[1] Note that has zero to do with supporting a synchronous 1.4Mbps flow for Red Book or such, it'll just fill the remote devices buffer as effectively and quickly as needed in order to prevent buffer starvation, and that's easy to observe watching your network activity.
 
Last edited:
Yeah so we aren't talking about flipping bits here rather common mode noise/broad spectrum ground loops entering the DAC and directly affecting perhaps the analog output stage.
We are talking about the same thing, you just keep moving the goal posts. Noise on ethernet networks is irrelevant if no bit errors happen. Now you are moving the goal posts to CM noise from ethernet perhaps getting into the analog section of a DAC, but you keep ignoring that the transformers are attenuating that minute amount of noise by 30-50dB before it perhaps gets to the analog section making it inaudible. BTW, well engineered equipment changes perhaps to doesn’t.

Yeah we are talking about two entirely different things.... bits are bits ... I am discussing common mode noise that travels over electrical connections regardless of the bits ... if you don't have a common mode noise problem its a non-issue for you. The first time I encountered it was a new HDMI cable on a new video card that was causing a massive hum on my studio monitors ... there was no direct connection, rather RFI ... RFI is common mode and doesn't pass over fiber
Not really, but you keep moving the goal posts. Noise on ethernet networks is seen as bit errors and retransmissions. HDMI is not ethernet so trying to use that as an example of noise on ethernet is nonsense.
 
We are talking about the same thing, you just keep moving the goal posts. Noise on ethernet networks is irrelevant if no bit errors happen. Now you are moving the goal posts to CM noise from ethernet perhaps getting into the analog section of a DAC, but you keep ignoring that the transformers are attenuating that minute amount of noise by 30-50dB before it perhaps gets to the analog section making it inaudible. BTW, well engineered equipment changes perhaps to doesn’t.


Not really, but you keep moving the goal posts. Noise on ethernet networks is seen as bit errors and retransmissions. HDMI is not ethernet so trying to use that as an example of noise on ethernet is nonsense.
Not moving the goal posts … you aren’t groking what I am saying

I am not discussing bits or bit errors … you can keep bringing up but it’s orthogonal

HDMI isn’t Ethernet but common mode noise/RFI gapped across a cable to my audio … what was the attenuation on that?

If you aren’t into understanding this just stick with RJ-45 copper Ethernet and be happy ✌️

It’s ok we don’t need to beat a dead horse ✌️
 
whelp ... POE is common mode so ... TP passes common mode, so not so simple
Sure using POE is giving you more posibility to pass interference along. But still its DC so a bit weird to call it common mode.
whelp ... POE is common mode so ... TP passes common mode, so not so simple
1779965321072.png


There is still galvanic isolation... An how would you do POE over fiber?
 
Not moving the goal posts … you aren’t groking what I am saying

I am not discussing bits or bit errors … you can keep bringing up but it’s orthogonal
I keep bringing it up because this thread is called “Fiberoptic Ethernet and bits on the wire”. Bit errors is how noise is seen in digital networks and if you don’t have bit errors, going to optical ethernet is pointless. You argue that CM noise is still there, and I keep telling you that it is attenuated and inaudible in well designed audio equipment.

HDMI isn’t Ethernet but common mode noise/RFI gapped across a cable to my audio … what was the attenuation on that?
Exactly, HDMI is not ethernet, so why do you keep bringing it up in an ethernet thread? HDMI has a common ground pin, ethernet does not. Ethernet is transformer coupled, HDMI is not. So ignoring those things while trying to equate noise in ethernet networks to noise on HDMI is disingenuous.

If you aren’t into understanding this just stick with RJ-45 copper Ethernet and be happy ✌️
The problem with your statement is I do understand it and I am telling you why it doesn’t matter on copper based ethernet unless you have bit errors. At that point you change the core subject to HDMI because that is the only example that you have.
 
The transformers still provide 30-50dB of attenuation to that higher frequency common mode noise.
Common-mode noise on copper Ethernet is normally rejected by the magnetics in two ways: the signal pair is differential, so equal-and-opposite currents in the windings cancel in the core, and the isolation transformer's interwinding capacitance is kept small so high-frequency common-mode currents don't capacitively jump from primary to secondary. The PHY-side common-mode choke (often integrated into the same magnetics module) adds a second stage, presenting high impedance to currents flowing in the same direction on both conductors. Under most operating conditions this is more than enough — common-mode rejection on a good 10/100/1000BASE-T magnetics module is on the order of 40–60 dB through the band of interest.


The transformers become inadequate in a handful of fairly specific situations.


The first is frequency. The choke and transformer behave like ideal components only over a limited band. Below a few hundred kHz the common-mode choke's impedance collapses, so power-frequency hum, ground loops between chassis at different mains potentials, and slow ground bounce ride straight through. At the other end, above roughly 100–300 MHz, parasitic interwinding capacitance starts to dominate and the transformer begins to look like a capacitor rather than an isolator. Fast transients — ESD strikes, nearby switching power supplies with hard edges, EFT bursts, lightning-induced surges — contain enormous energy above that corner and couple capacitively across the windings regardless of the turns ratio.


The second is imbalance. CMRR depends on the two halves of the pair being electrically symmetric — equal trace lengths, equal parasitic capacitance to ground, equal termination. Any asymmetry converts a portion of incoming common-mode noise into differential-mode noise, which the PHY cannot distinguish from signal. PCB layout mistakes (unequal stub lengths from the magnetics to the RJ-45, one side of the pair routed over a split plane, a Bob Smith termination implemented with mismatched resistors or with one leg missing) are the usual culprits. Cheap or off-spec magnetics with poor winding symmetry do the same thing internally.


The third is saturation. If a large DC or low-frequency common-mode current flows — for example, when the cable shield is bonded at both ends across a ground-potential difference, or when a nearby high-current conductor induces a net current in the pair — the choke's core can partially saturate, its inductance drops, and its rejection at the frequencies you care about collapses with it. This is why PoE designs are careful about center-tap currents and why shielded cabling is often bonded at only one end.


The fourth is the limits of the isolation barrier itself. Magnetics are typically rated for around 1500 Vrms hi-pot, sometimes 2250 V or 3 kV for industrial parts. A direct lightning strike, a fault that puts mains voltage on the cable, or a several-kilovolt ESD discharge will arc across the barrier (or across the interwinding capacitance via displacement current) and deliver a transient straight to the PHY. This is why robust designs add TVS diodes or gas discharge tubes on the line side and sometimes on the PHY side as well.


The fifth — and the one most often missed in a working but noisy system — is the return path. The magnetics only reject common-mode currents that have a path to flow as common-mode. If your chassis ground, the cable shield, and the PHY's analog ground are tied together through a low-impedance path that bypasses the choke (a shield pigtail bonded to chassis right next to the PHY ground pour, for instance), high-frequency noise will take that shortcut and appear on the PHY side without ever having to cross the transformer. The classic Bob Smith termination network — the 75 Ω resistors from each pair's center tap to a common node, then to chassis through a high-voltage cap — exists specifically to give common-mode currents a controlled, terminated path to chassis instead of letting them couple through the magnetics or radiate.


So the short answer: the transformers fail to block common-mode noise when the noise is outside their useful band (very low or very high frequency), when pair or termination imbalance converts CM to DM before the transformer sees it, when DC bias saturates the choke, when the transient amplitude exceeds the isolation barrier, or when an unintended low-impedance path lets CM currents bypass the magnetics entirely. So, no, it doesn't take care of everything. Whether it matters depends on your system. In many cases its simply easier and cheaper to go fiberoptic rather than do extensive ground loop mitigations as described above.
 
I keep bringing it up because this thread is called “Fiberoptic Ethernet and bits on the wire”. Bit errors is how noise is seen in digital networks and if you don’t have bit errors, going to optical ethernet is pointless. You argue that CM noise is still there, and I keep telling you that it is attenuated and inaudible in well designed audio equipment.
To be clear, CM attenuation and 'inaudibility' is not something that 'well designed' audio equipment is immune from. That is simply handwaving and dismissing the topic. The topic is not the title, rather the post. No joke that both fiberoptic and copper ethernet perfectly transmit bits on the wire. No question. That isn't the purpose of the post.

Common mode noise is related but not the same as a ground loop. It is often not the fault of a single piece of equipment (but may be) rather the interactions between boxes. Let me spell this out:

A ground loop is the physical mechanism that most often creates common-mode noise on an Ethernet cable, so the two concepts are tightly linked but not identical. Common-mode noise is the symptom — a voltage or current that appears equally on both conductors of a pair with respect to some reference. A ground loop is one of the most common sources of that symptom.

The setup is simple. Two pieces of equipment — say a switch in a wiring closet and a PC on a desk — each have their own connection to "ground." That ground might be the safety earth at the wall outlet, the building steel, a rack ground bar, or just the chassis bonded to mains earth through the power supply. In an ideal world every one of those ground points sits at exactly the same potential. In the real world they don't. The earth conductor in the building's wiring has resistance and inductance, other equipment on the same circuits is dumping return current into it, nearby transformers and motors are inducing voltages in the loops it forms, and the result is that the chassis of the switch and the chassis of the PC sit at slightly different potentials. The difference might be a few millivolts of 60 Hz hum in a benign installation, or several volts of broadband noise in an industrial plant, or kilovolts during a lightning event.

Now you connect those two chassis together with a copper Ethernet cable. The cable's conductors, the magnetics' center taps, the Bob Smith termination, the cable shield if you have one, and any parasitic capacitance to chassis all form paths between the two ground references. A current flows around the loop: out one end's ground, along the cable, into the other end's ground, back through the building's earth conductors to where it started. That current is by definition common-mode on the Ethernet cable, because it flows in the same direction on every conductor in the bundle. The voltage that drives it appears, again in common-mode, across the magnetics.

So the relationship is causal and direct: a ground potential difference plus a conductive path between the two grounds equals a ground loop, and a ground loop forces common-mode current through whatever conductors complete the loop — including the Ethernet pair. The Ethernet magnetics are specifically designed to break this loop at DC and low frequencies by providing galvanic isolation, which is why a properly working transformer-isolated PHY tolerates a couple of volts of inter-chassis ground difference without any signal degradation at all. The differential signal rides through the transformer; the common-mode loop current is blocked by the isolation and by the common-mode choke.

The trouble starts when the loop's drive voltage contains energy in bands the magnetics can't reject, or when the loop has a path that bypasses the magnetics. Mains-frequency hum from a ground loop is below the choke's useful impedance, so it shows up as a slow CM offset; the transformer's galvanic isolation keeps it from doing harm at the signal level, but it can still cause problems for audio or video equipment sharing the same chassis. Fast transients from the loop — switching noise from a nearby VFD, ESD events, lightning surges — contain energy well above the transformer's parasitic-capacitance corner, and those couple across the isolation barrier and show up on the PHY side. And if you've bonded the cable shield to chassis at both ends, you've created a deliberate low-impedance path for the loop current that runs in parallel with the magnetics rather than through them; the shield carries the CM current happily and radiates it into the pair through any imbalance in the cable construction.

This is why the standard mitigations all attack the loop rather than the noise. Bonding the shield at only one end breaks the conductive path so no DC or low-frequency loop current can flow. Fiber between buildings or between equipment at very different ground potentials eliminates the copper path entirely. Isolation transformers on power feeds, common-bonded ground bars in a rack, and star grounding all aim to reduce the potential difference that drives the loop in the first place. The Bob Smith termination doesn't break the loop — it terminates the CM path in its characteristic impedance so any residual CM current sees a matched load rather than reflecting and ringing. And the PHY's own CMRR, plus careful pair balance on the PCB, ensures that whatever CM current does flow doesn't get converted into differential noise that the receiver would mistake for signal.

The clean way to think about it: common-mode noise is what you measure, a ground loop is one mechanism that produces it, and the Ethernet magnetics are designed on the assumption that ground loops exist and must be tolerated. They handle the slow, low-energy case by galvanic isolation and the fast, moderate-energy case by choke impedance and pair balance. They stop being adequate exactly when the loop's drive voltage contains energy outside the magnetics' working band, or when something in the system gives the loop current a path that doesn't go through the magnetics.
 
So the short answer: the transformers fail to block common-mode noise when the noise is outside their useful band (very low or very high frequency),
Transformers never block CM noise, they attenuate it.

when pair or termination imbalance converts CM to DM before the transformer sees it,
The transformer is the first thing the ethernet cables sees.

when DC bias saturates the choke
Red herring...
when the transient amplitude exceeds the isolation barrier, or when an unintended low-impedance path lets CM currents bypass the magnetics entirely.
And the result would be bit errors, which TCP would handle.

In many cases its simply easier and cheaper to go fiberoptic rather than do extensive ground loop mitigations as described above.
You said you weren’t selling anything, this sounds like a sales pitch rather than engineering. All you need to do is check your switch for bit errors, don’t see any, no need for optical ethernet.
 
where some "thing" in a computing environment needs to be sync'ed to a master clock, this is done via ntp (Network Time Protocol) and ntp is a protocol that runs over tcp/ip so this is an amazing thing... a precision master clock that keeps devices/databases/applications in sync yet it runs over a non-precision (relative to time) protocol. ntp is accurate to a few milliseconds
Indeed PTPv2 is used for sync in the microseconds->?nanoseconds range -- there is an entire set of precision time protocols for ethernet... used by Ravenna and professional multichannel sound systems. An advantage of pro-grade networking equipment is that it implements these protocols e.g. Netgear AV series, although most home audio doesn't need because its stereo.
 
Never had any issue with audible noise introduced by a copper lan connection, anyone else had?
 
Never had any issue with audible noise introduced by a copper lan connection, anyone else had?
Honestly if you aren't having an issue then you are all set... I see you have some Atmos and when distributed from an AV Amp all is good, but some systems are distributing via AES67/Ravenna and these want PTPv2 (e.g. Netgear AV series but also inexpensive Mikrotik etc) and these pro-grade switches are tyically SFP+ or SFP28 based so can handle both RJ-45 copper and fiberoptic... IEEE 802.1AS are a new set of networking standards for AVB etc ...
 
Back
Top Bottom