Hi

I am working on a product that connects to an access point via ethernet 100 Base TX
I am having some problems with common mode noise on the ethernet cable, and have been trying all sorts of tricks, nothing help as of now

So staring at the signals on the cable, there is a lot of traffic even though we just use it for sub kB/s traffic. The reason for the traffic is the MLT-3 encoding, so even with nothing to transfer, the line is busy as xxxx

So it occurred to me, why not just disable the line, and send a preamble with some data, and shut down the line again to remove this EMC issue. It seems there is a low power mode, that could be used.

Anyone tried something like this?

We are using DP83822

:https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467

--
Klaus

09.04.22 10:59, Klaus Kragelund wrote:
>Hi
>
>I am working on a product that connects to an access point via ethernet 100 Base TX
>I am having some problems with common mode noise on the ethernet cable, and have been trying all sorts of tricks, nothing help as of now
>
>So staring at the signals on the cable, there is a lot of traffic even though we just use it for sub kB/s traffic. The reason for the traffic is the MLT-3 encoding, so even with nothing to transfer, the line is busy as xxxx
>
>So it occurred to me, why not just disable the line, and send a preamble with some data, and shut down the line again to remove this EMC issue. It seems there is a low power mode, that could be used.
>
>Anyone tried something like this?
>
>We are using DP83822
>
>:https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467
>
>
The chip supports EEE mode

https://www.juniper.net/documentation/us/en/software/junos/interfaces-ethernet-switches/topics/topic-map/switches-interface-eee.html#:~:text=EEE%20uses%20a%20signaling%20protocol,when%20there%20is%20no%20traffic.

>

--
Klaus

On Saturday, April 9, 2022 at 1:59:15 AM UTC-7, Klaus Kragelund wrote:
> Hi
>
> I am working on a product that connects to an access point via ethernet 100 Base TX
> I am having some problems with common mode noise on the ethernet cable,...

Huh? 100baseTX is transformer-coupled, why would common mode be important?
Are you doing power-over-Ethernet and having noisy power?

On 4/9/2022 1:59 AM, Klaus Kragelund wrote:
> I am working on a product that connects to an access point via ethernet 100
> Base TX

Most "access points" are *wireless* devices acting as gateways onto a wired
network. Are you trying to connect to the wired port of the AP?

> I am having some problems with common mode noise on the ethernet cable, and
> have been trying all sorts of tricks, nothing help as of now
>
> So staring at the signals on the cable, there is a lot of traffic even though
> we just use it for sub kB/s traffic. The reason for the traffic is the MLT-3
> encoding, so even with nothing to transfer, the line is busy as xxxx

Unless you have a point-to-point link, there will almost always be "traffic"
on the line as many protocols rely on the switch to replicate the traffic on
all ports for other protocols to function properly.

E.g., during a DHCP/BOOTP client request, the client *broadcasts* a message to
locate any potential DHCP/BOOTP servers on the network. The switch must
replicate this message on all of its ports to ensure all hosts in the network
get a chance to see it (because the *intended* destination isn't known to the
sender)

Because the client doesn't (yet) have an IP address, any server(s) receiving
it's "discovery" broadcast will *broadcast* a reply, *offering* a lease to that
client -- indicating a "server ID" for THAT server (multiple servers can
attempt to "offer").

The client will then *broadcast* a "request" -- including an extra ARP to see
if any other node has the same (offered) IP address. etc.

[You can run something like tcpdump/wireshark (even on a wired network) to
examine the actual traffic on your network.]

> So it occurred to me, why not just disable the line, and send a preamble with
> some data, and shut down the line again to remove this EMC issue. It seems
> there is a low power mode, that could be used.

So, you're saying the "idle traffic" is the problem that you want to
eliminate? Is it's quantity or "frequency" the issue?

Do you have complete control over the network and the hosts on it? E.g.,
if your node is "deaf" because the connection is "shut off", then you
have to ensure that it's configuration is baked into the network's
design; so the IP address it is using (while "shut off") won't be
delegated to some other node while your node "isn't watching".

Otherwise, each time you "reconnect" to the network, you will have to
make sure your presence is known.

> Anyone tried something like this?
>
> We are using DP83822
>
> :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467

On 09-Apr-22 7:12 pm, Klaus Kragelund wrote:
> 09.04.22 10:59, Klaus Kragelund   wrote:
>> Hi
>>
>> I am working on a product that connects to an access point via
>> ethernet 100 Base TX
>> I am having some problems with common mode noise on the ethernet
>> cable, and have been trying all sorts of tricks, nothing help as of now
>>
>> So staring at the signals on the cable, there is a lot of traffic even
>> though we just use it for sub kB/s traffic. The reason for the traffic
>> is the MLT-3 encoding, so even with nothing to transfer, the line is
>> busy as xxxx
>>
>> So it occurred to me, why not just disable the line, and send a
>> preamble with some data, and shut down the line again to remove this
>> EMC issue. It seems there is a low power mode, that could be used.
>>
>> Anyone tried something like this?
>>
>> We are using DP83822
>>
>> :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467
>>
>>
>>
> The chip supports EEE mode
> https://www.juniper.net/documentation/us/en/software/junos/interfaces-ethernet-switches/topics/topic-map/switches-interface-eee.html#:~:text=EEE%20uses%20a%20signaling%20protocol,when%20there%20is%20no%20traffic.
>
>
>>
>
>
> --
> Klaus

How is the common mode noise causing you a problem?

Sylvia.

On 09/04/2022 09:59, Klaus Kragelund wrote:
> Hi
>
> I am working on a product that connects to an access point via ethernet
> 100 Base TX
> I am having some problems with common mode noise on the ethernet cable,
> and have been trying all sorts of tricks, nothing help as of now
>
> So staring at the signals on the cable, there is a lot of traffic even
> though we just use it for sub kB/s traffic. The reason for the traffic
> is the MLT-3 encoding, so even with nothing to transfer, the line is
> busy as xxxx
>
> So it occurred to me, why not just disable the line, and send a preamble
> with some data, and shut down the line again to remove this EMC issue.
> It seems there is a low power mode, that could be used.
>
> Anyone tried something like this?
>
> We are using DP83822
>
> :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467
>
>
>
>
> --
> Klaus

Ethernet is normally transformer coupled so any common mode noise may be
down to the transformer interwinding capacity and easily dealt with by
the traditional ferrite ring over the cable?

We recently heard of ferrite beads able to work at 50Hz :)

piglet

On 9.4.22 11.59, Klaus Kragelund wrote:
> Hi
>
> I am working on a product that connects to an access point via ethernet
> 100 Base TX
> I am having some problems with common mode noise on the ethernet cable,
> and have been trying all sorts of tricks, nothing help as of now
>
> So staring at the signals on the cable, there is a lot of traffic even
> though we just use it for sub kB/s traffic. The reason for the traffic
> is the MLT-3 encoding, so even with nothing to transfer, the line is
> busy as xxxx
>
> So it occurred to me, why not just disable the line, and send a preamble
> with some data, and shut down the line again to remove this EMC issue.
> It seems there is a low power mode, that could be used.
>
> Anyone tried something like this?
>
> We are using DP83822
>
> :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467
>
>
>
>
> --
> Klaus

100BaseTX sends idle signals all the time when there is nothing else to
send.

If you have access to the switch at the other end of the link or the
configuration of the DP83822, force the link to 10BaseT to stop the
idles. There will still be link pulses, but less often.

--

-TV

On a sunny day (Sat, 09 Apr 2022 10:59:07 +0200) it happened Klaus Kragelund
<klauskvik@hotmail.com> wrote in <tscheppe.1ui5uq8q91brg@nntp.aioe.org>:

>Hi
>
>I am working on a product that connects to an access point via ethernet 100 Base TX
>I am having some problems with common mode noise on the ethernet cable, and have been trying all sorts of tricks, nothing help
>as of now
>
>So staring at the signals on the cable, there is a lot of traffic even though we just use it for sub kB/s traffic. The reason
>for the traffic is the MLT-3 encoding, so even with nothing to transfer, the line is busy as xxxx
>
>So it occurred to me, why not just disable the line, and send a preamble with some data, and shut down the line again to remove
>this EMC issue. It seems there is a low power mode, that could be used.
>
>Anyone tried something like this?
>
>We are using DP83822
>
>:https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467

In the eighties we had a similar problem in a large industrial plant with PLCs connected to a computer
Decided to go optical, worked perfectly.
Like this (have not tried that one):
https://www.amazon.com/Tripp-Lite-N784-001-ST-Multimode-Converter/dp/B000IAOL84/ref=sr_1_10?keywords=fiber%2Bto%2Bethernet%2Bconverter&qid=1649502290&sr=8-10&th=1erface tings you can buy.

>
>--
>Klaus
>

09.04.22 11:32, Sylvia Else wrote:
>On 09-Apr-22 7:12 pm, Klaus Kragelund wrote:
>> 09.04.22 10:59, Klaus Kragelund�� wrote:
>>> Hi
>>>
>>> I am working on a product that connects to an access point via
>>> ethernet 100 Base TX
>>> I am having some problems with common mode noise on the ethernet
>>> cable, and have been trying all sorts of tricks, nothing help as of now
>>>
>>> So staring at the signals on the cable, there is a lot of traffic even
>>> though we just use it for sub kB/s traffic. The reason for the traffic
>>> is the MLT-3 encoding, so even with nothing to transfer, the line is
>>> busy as xxxx
>>>
>>> So it occurred to me, why not just disable the line, and send a
>>> preamble with some data, and shut down the line again to remove this
>>> EMC issue. It seems there is a low power mode, that could be used.
>>>
>>> Anyone tried something like this?
>>>
>>> We are using DP83822
>>>
>>> :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467
>>>
>>>
>>>
>> The chip supports EEE mode
>> https://www.juniper.net/documentation/us/en/software/junos/interfaces-ethernet-switches/topics/topic-map/switches-interface-eee.html#:~:text=EEE%20uses%20a%20signaling%20protocol,when%20there%20is%20no%20traffic.
>>
>>
>>>
>>
>>
>> --
>> Klaus
>
>How is the common mode noise causing you a problem?
>
I am seeing assymetric waveforms on TD+ and TD-, so the resultant addition if the signals results in a non zero voltage on the line.

Ethernet compliance allows for 50mV, and I am seeking a lot of noise above 10MHz in the conducted ethernet tesrs
..
It is possible that the cause is poor layout and or non optimal cable shield

I could spend more time on testing and interate the PCB, but a SW mod is a little eas

--
Klaus

09.04.22 11:29, whit3rd wrote:
>On Saturday, April 9, 2022 at 1:59:15 AM UTC-7, Klaus Kragelund wrote:
>> Hi
>>
>> I am working on a product that connects to an access point via ethernet 100 Base TX
>> I am having some problems with common mode noise on the ethernet cable,...
>
>Huh? 100baseTX is transformer-coupled, why would common mode be important?
>Are you doing power-over-Ethernet and having noisy power?
It is transformer coupled including a CM transformer, but assymetry of the MDI signal priduces common node noise

--
Klaus

09.04.22 11:29, Don Y wrote:
>On 4/9/2022 1:59 AM, Klaus Kragelund wrote:
>> I am working on a product that connects to an access point via ethernet 100
>> Base TX
>
>Most "access points" are *wireless* devices acting as gateways onto a wired
>network. Are you trying to connect to the wired port of the AP?

Yes, this is a wired Ethernet product
>
>> I am having some problems with common mode noise on the ethernet cable, and
>> have been trying all sorts of tricks, nothing help as of now
>>
>> So staring at the signals on the cable, there is a lot of traffic even though
>> we just use it for sub kB/s traffic. The reason for the traffic is the MLT-3
>> encoding, so even with nothing to transfer, the line is busy as xxxx
>
>Unless you have a point-to-point link, there will almost always be "traffic"
>on the line as many protocols rely on the switch to replicate the traffic on
>all ports for other protocols to function properly.

That is a good point, perhaps it's not possible to be sure that this connection is the only one

>
>E.g., during a DHCP/BOOTP client request, the client *broadcasts* a message to
>locate any potential DHCP/BOOTP servers on the network. The switch must
>replicate this message on all of its ports to ensure all hosts in the network
>get a chance to see it (because the *intended* destination isn't known to the
>sender)
>
>Because the client doesn't (yet) have an IP address, any server(s) receiving
>it's "discovery" broadcast will *broadcast* a reply, *offering* a lease to that
>client -- indicating a "server ID" for THAT server (multiple servers can
>attempt to "offer").
>
>The client will then *broadcast* a "request" -- including an extra ARP to see
>if any other node has the same (offered) IP address. etc.
>
>[You can run something like tcpdump/wireshark (even on a wired network) to
>examine the actual traffic on your network.]
>
>> So it occurred to me, why not just disable the line, and send a preamble with
>> some data, and shut down the line again to remove this EMC issue. It seems
>> there is a low power mode, that could be used.
>
>So, you're saying the "idle traffic" is the problem that you want to
>eliminate? Is it's quantity or "frequency" the issue?
>
>Do you have complete control over the network and the hosts on it? E.g.,
>if your node is "deaf" because the connection is "shut off", then you
>have to ensure that it's configuration is baked into the network's
>design; so the IP address it is using (while "shut off") won't be
>delegated to some other node while your node "isn't watching".
>
>Otherwise, each time you "reconnect" to the network, you will have to
>make sure your presence is known.

Yes. I could power it down totally, but I think the reinitualization will take longer than the settle time of the test receiver

--
Klaus

09.04.22 12:00, piglet wrote:
>On 09/04/2022 09:59, Klaus Kragelund wrote:
>> Hi
>>
>> I am working on a product that connects to an access point via ethernet
>> 100 Base TX
>> I am having some problems with common mode noise on the ethernet cable,
>> and have been trying all sorts of tricks, nothing help as of now
>>
>> So staring at the signals on the cable, there is a lot of traffic even
>> though we just use it for sub kB/s traffic. The reason for the traffic
>> is the MLT-3 encoding, so even with nothing to transfer, the line is
>> busy as xxxx
>>
>> So it occurred to me, why not just disable the line, and send a preamble
>> with some data, and shut down the line again to remove this EMC issue.
>> It seems there is a low power mode, that could be used.
>>
>> Anyone tried something like this?
>>
>> We are using DP83822
>>
>> :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467
>>
>>
>>
>>
>> --
>> Klaus
>
>Ethernet is normally transformer coupled so any common mode noise may be
>down to the transformer interwinding capacity and easily dealt with by
>the traditional ferrite ring over the cable?
>
>We recently heard of ferrite beads able to work at 50Hz :)
>
I cannot add a ferrite ring, but are looking into adding beads to VDD, AVD and GND

I am also adding provisions for pF caps between TX and GND to reduce the slew rates

--
Klaus

On 09-Apr-22 10:10 pm, Klaus Kragelund wrote:
> 09.04.22 11:32, Sylvia Else  wrote:
>> On 09-Apr-22 7:12 pm, Klaus Kragelund wrote:
>>> 09.04.22 10:59, Klaus Kragelund�� wrote:
>>>> Hi
>>>>
>>>> I am working on a product that connects to an access point via
>>>> ethernet 100 Base TX
>>>> I am having some problems with common mode noise on the ethernet
>>>> cable, and have been trying all sorts of tricks, nothing help as of now
>>>>
>>>> So staring at the signals on the cable, there is a lot of traffic
>>>> even though we just use it for sub kB/s traffic. The reason for the
>>>> traffic is the MLT-3 encoding, so even with nothing to transfer, the
>>>> line is busy as xxxx
>>>>
>>>> So it occurred to me, why not just disable the line, and send a
>>>> preamble with some data, and shut down the line again to remove this
>>>> EMC issue. It seems there is a low power mode, that could be used.
>>>>
>>>> Anyone tried something like this?
>>>>
>>>> We are using DP83822
>>>>
>>>> :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467
>>>>
>>>>
>>>>
>>> The chip supports EEE mode
>>> https://www.juniper.net/documentation/us/en/software/junos/interfaces-ethernet-switches/topics/topic-map/switches-interface-eee.html#:~:text=EEE%20uses%20a%20signaling%20protocol,when%20there%20is%20no%20traffic.
>>>
>>>
>>>>
>>>
>>>
>>> --
>>> Klaus
>>
>> How is the common mode noise causing you a problem?
>>
> I am seeing assymetric waveforms on TD+ and TD-, so the resultant
> addition if the signals results in a non zero voltage on the line.
> Ethernet compliance allows for 50mV, and I am seeking a lot of noise
> above 10MHz in the conducted ethernet tesrs
> . It is possible that the cause is poor layout and or non optimal cable
> shield
>
> I could spend more time on testing and interate the PCB, but a SW mod is
> a little eas
>
>
> --
> Klaus

Not common mode, then.

I don't see how disabling the line, whatever that involves, is going to
help. The noise will still be there when the line is enabled to transmit
data.

Sylvia.

09.04.22 12:59, Tauno Voipio wrote:
>On 9.4.22 11.59, Klaus Kragelund wrote:
>> Hi
>>
>> I am working on a product that connects to an access point via ethernet
>> 100 Base TX
>> I am having some problems with common mode noise on the ethernet cable,
>> and have been trying all sorts of tricks, nothing help as of now
>>
>> So staring at the signals on the cable, there is a lot of traffic even
>> though we just use it for sub kB/s traffic. The reason for the traffic
>> is the MLT-3 encoding, so even with nothing to transfer, the line is
>> busy as xxxx
>>
>> So it occurred to me, why not just disable the line, and send a preamble
>> with some data, and shut down the line again to remove this EMC issue.
>> It seems there is a low power mode, that could be used.
>>
>> Anyone tried something like this?
>>
>> We are using DP83822
>>
>> :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467
>>
>>
>>
>>
>> --
>> Klaus
>
>
>100BaseTX sends idle signals all the time when there is nothing else to
>send.
>
>If you have access to the switch at the other end of the link or the
>configuration of the DP83822, force the link to 10BaseT to stop the
>idles. There will still be link pulses, but less often.
>

OK, so 10BaseTX has less idle pulses than 100BaseTX?

Great suggestion ?

I actually did suggest lowering the speed to 10BaseTX, but it may not be allowed

--
Klaus

On 09/04/2022 14:37, Klaus Kragelund wrote:
> 09.04.22 12:59, Tauno Voipio  wrote:

>>
>> 100BaseTX sends idle signals all the time when there is nothing else
>> to send.
>>
>> If you have access to the switch at the other end of the link or the
>> configuration of the DP83822, force the link to 10BaseT to stop the
>> idles. There will still be link pulses, but less often.
>>
>
> OK, so 10BaseTX has less idle pulses than 100BaseTX?
>
> Great suggestion ?
>
> I actually did suggest lowering the speed to 10BaseTX, but it may not be
> allowed
>

You will want to disable Auto MDI-X. The protocol used by that to
determine crossover cables and connection speeds involves regular pulses
on the lines.

On 4/9/2022 5:17 AM, Klaus Kragelund wrote:
> 09.04.22 11:29, Don Y wrote:
>> On 4/9/2022 1:59 AM, Klaus Kragelund wrote:
>>> I am working on a product that connects to an access point via ethernet 100
>>> Base TX
>>
>> Most "access points" are *wireless* devices acting as gateways onto a wired
>> network. Are you trying to connect to the wired port of the AP?
>
> Yes, this is a wired Ethernet product

So, what is the "access point" to which you refer?

>>> I am having some problems with common mode noise on the ethernet cable, and
>>> have been trying all sorts of tricks, nothing help as of now
>>>
>>> So staring at the signals on the cable, there is a lot of traffic even
>>> though we just use it for sub kB/s traffic. The reason for the traffic is
>>> the MLT-3 encoding, so even with nothing to transfer, the line is busy as xxxx
>>
>> Unless you have a point-to-point link, there will almost always be "traffic"
>> on the line as many protocols rely on the switch to replicate the traffic on
>> all ports for other protocols to function properly.
>
> That is a good point, perhaps it's not possible to be sure that this connection
> is the only one

In general, you can't control:
- the number and "character" of nodes connected
- the type/quality/length of cable (incl "homemade" cables)
- how that cable is routed (wrt mains cables and other noise sources)
- the make/model/type of switch
- the nodes that decide to "chat with you"
- the adherence of other nodes to the correct protocols
- the benevolence of other nodes
- the connection/isolation of your device from the above

(connecting to an ethernet comes at some peril)

If you've rolled your own stack, be sure to examine it for the
numerous vulnerabilities/exploits that "adversaries" may deploy
against you.

If you've "inherited" a protocol stack, it is wise to make sure you
understand the implementation, in detail, to be harden against
likely vulnerabilities.

You can make certain claims about the "requirements" to use your
device -- but those will likely never be checked by your customers
and, even if THEY have failed to comply, YOU will be seen as the
faulty component.

>> So, you're saying the "idle traffic" is the problem that you want to
>> eliminate? Is it's quantity or "frequency" the issue?
>>
>> Do you have complete control over the network and the hosts on it? E.g.,
>> if your node is "deaf" because the connection is "shut off", then you
>> have to ensure that it's configuration is baked into the network's
>> design; so the IP address it is using (while "shut off") won't be
>> delegated to some other node while your node "isn't watching".
>>
>> Otherwise, each time you "reconnect" to the network, you will have to
>> make sure your presence is known.
>
> Yes. I could power it down totally, but I think the reinitualization will take
> longer than the settle time of the test receiver

You can try an energy efficient switch -- but, there's no guarantee that you
will be deployed with one and no easy way to detect that you are operating in
that environment whereby you can "refuse" to operate (escalating the "problem"
before it becomes an *intermittent* "noise" problem). And, the problem will
reappear when the link comes back up (which can be at the behest of some
OTHER node deciding it needs to talk to/at you).

You can disable autonegotiation and force the NIC to use 10BaseT -- which cuts
the peak throughput and increases latency but may be adequate for your needs.

You can go a different (i/f) route and employ a media converter to bridge
to ethernet "past" your device (e.g., optical in your device to converter
to copper). Or, even something like a traditional serial port talking to a
"one port terminal server" acting as a media converter (I have such a
configuration for my PROM programmer)

Or, you can ask yourself what is *so* unique about your design/implementation
that *it* has this problem where others don't (?) Are you trying to do
something particularly sensitive? Bad layout? etc.

On Sat, 09 Apr 2022 10:59:07 +0200, Klaus Kragelund
<klauskvik@hotmail.com> wrote:

>Hi
>
>I am working on a product that connects to an access point via ethernet 100 Base TX
>I am having some problems with common mode noise on the ethernet cable, and have been trying all sorts of tricks, nothing help as of now
>
>So staring at the signals on the cable, there is a lot of traffic even though we just use it for sub kB/s traffic. The reason for the traffic is the MLT-3 encoding, so even with nothing to transfer, the line is busy as xxxx
>
>So it occurred to me, why not just disable the line, and send a preamble with some data, and shut down the line again to remove this EMC issue. It seems there is a low power mode, that could be used.
>
>Anyone tried something like this?
>
>We are using DP83822
>
>:https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467

You might go optical, with SFP modules.

--

I yam what I yam - Popeye

On Sat, 09 Apr 2022 14:10:34 +0200, Klaus Kragelund
<klauskvik@hotmail.com> wrote:

>09.04.22 11:32, Sylvia Else wrote:
>>On 09-Apr-22 7:12 pm, Klaus Kragelund wrote:
>>> 09.04.22 10:59, Klaus Kragelund wrote:
>>>> Hi
>>>>
>>>> I am working on a product that connects to an access point via
>>>> ethernet 100 Base TX
>>>> I am having some problems with common mode noise on the ethernet
>>>> cable, and have been trying all sorts of tricks, nothing help as of now
>>>>
>>>> So staring at the signals on the cable, there is a lot of traffic even
>>>> though we just use it for sub kB/s traffic. The reason for the traffic
>>>> is the MLT-3 encoding, so even with nothing to transfer, the line is
>>>> busy as xxxx
>>>>
>>>> So it occurred to me, why not just disable the line, and send a
>>>> preamble with some data, and shut down the line again to remove this
>>>> EMC issue. It seems there is a low power mode, that could be used.
>>>>
>>>> Anyone tried something like this?
>>>>
>>>> We are using DP83822
>>>>
>>>> :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467
>>>>
>>>>
>>>>
>>> The chip supports EEE mode
>>> https://www.juniper.net/documentation/us/en/software/junos/interfaces-ethernet-switches/topics/topic-map/switches-interface-eee.html#:~:text=EEE%20uses%20a%20signaling%20protocol,when%20there%20is%20no%20traffic.
>>>
>>>
>>>>
>>>
>>>
>>> --
>>> Klaus
>>
>>How is the common mode noise causing you a problem?
>>
>I am seeing asymmetric waveforms on TD+ and TD-, so the resultant addition if the signals results in a non zero voltage on the line.
>
>Ethernet compliance allows for 50mV, and I am seeking a lot of noise above 10MHz in the conducted ethernet tesrs
>.
>It is possible that the cause is poor layout and or non optimal cable shield

That would be my guess, but only after determining that the receiver
transformer coupling is in fact achieving galvanic isolation, or
ground currents in the facility may cause the receivers to stray out
of their allowed common-mode DC voltage offset range. This can be
directly tested using a battery and a potentiometer.

The cable must be twisted pair with at least a specified number of
twists per foot, and although not required, may and maybe should be
shielded. These should together reduce asymmetry.

And, as another has mentioned, the PoE supply may be contaminating
things. Again, this is directly testable. If this is happening, a
cable shield may help.

>
>I could spend more time on testing and interate the PCB, but a SW mod is a little easier

I kinda doubt that a SW fix will solve such a problem.

Joe Gwinn

On 4/9/2022 9:44 AM, Joe Gwinn wrote:
> On Sat, 09 Apr 2022 14:10:34 +0200, Klaus Kragelund
> <klauskvik@hotmail.com> wrote:
>
>> 09.04.22 11:32, Sylvia Else wrote:
>>> On 09-Apr-22 7:12 pm, Klaus Kragelund wrote:
>>>> 09.04.22 10:59, Klaus Kragelund wrote:
>>>>> Hi
>>>>>
>>>>> I am working on a product that connects to an access point via
>>>>> ethernet 100 Base TX
>>>>> I am having some problems with common mode noise on the ethernet
>>>>> cable, and have been trying all sorts of tricks, nothing help as of now
>>>>>
>>>>> So staring at the signals on the cable, there is a lot of traffic even
>>>>> though we just use it for sub kB/s traffic. The reason for the traffic
>>>>> is the MLT-3 encoding, so even with nothing to transfer, the line is
>>>>> busy as xxxx
>>>>>
>>>>> So it occurred to me, why not just disable the line, and send a
>>>>> preamble with some data, and shut down the line again to remove this
>>>>> EMC issue. It seems there is a low power mode, that could be used.
>>>>>
>>>>> Anyone tried something like this?
>>>>>
>>>>> We are using DP83822
>>>>>
>>>>> :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467
>>>>>
>>>>>
>>>>>
>>>> The chip supports EEE mode
>>>> https://www.juniper.net/documentation/us/en/software/junos/interfaces-ethernet-switches/topics/topic-map/switches-interface-eee.html#:~:text=EEE%20uses%20a%20signaling%20protocol,when%20there%20is%20no%20traffic.
>>>>
>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Klaus
>>>
>>> How is the common mode noise causing you a problem?
>>>
>> I am seeing asymmetric waveforms on TD+ and TD-, so the resultant addition if the signals results in a non zero voltage on the line.
>>
>> Ethernet compliance allows for 50mV, and I am seeking a lot of noise above 10MHz in the conducted ethernet tesrs
>> .
>> It is possible that the cause is poor layout and or non optimal cable shield
>
> That would be my guess, but only after determining that the receiver
> transformer coupling is in fact achieving galvanic isolation, or
> ground currents in the facility may cause the receivers to stray out
> of their allowed common-mode DC voltage offset range. This can be
> directly tested using a battery and a potentiometer.
>
> The cable must be twisted pair with at least a specified number of
> twists per foot, and although not required, may and maybe should be
> shielded. These should together reduce asymmetry.

But you can't count on your customer using "quality cables" -- even
if you supply them! <frown>

> And, as another has mentioned, the PoE supply may be contaminating
> things. Again, this is directly testable. If this is happening, a
> cable shield may help.

Que? I don't see PoE being used, here.

>> I could spend more time on testing and interate the PCB, but a SW mod is a little easier
>
> I kinda doubt that a SW fix will solve such a problem.

*If* the problem was noise getting into some low-level, high impedance
measurement, one could envision arranging for the network activity
(which appears to be largely one-directional?) to occur when those
measurements were NOT being taken.

[I'm still looking for clarification as to how the "noise" is a problem]

But, as I've said elsewhere, it means having complete control over the
entire fabric to ensure something else isn't "chattering" when you'd
prefer the line quiet. (the same problem exists if you power down the
link)

On 09/04/2022 13.07, Jan Panteltje wrote:
> On a sunny day (Sat, 09 Apr 2022 10:59:07 +0200) it happened Klaus Kragelund
> <klauskvik@hotmail.com> wrote in <tscheppe.1ui5uq8q91brg@nntp.aioe.org>:
>
>> Hi
>>
>> I am working on a product that connects to an access point via ethernet 100 Base TX
>> I am having some problems with common mode noise on the ethernet cable, and have been trying all sorts of tricks, nothing help
>> as of now
>>
>> So staring at the signals on the cable, there is a lot of traffic even though we just use it for sub kB/s traffic. The reason
>> for the traffic is the MLT-3 encoding, so even with nothing to transfer, the line is busy as xxxx
>>
>> So it occurred to me, why not just disable the line, and send a preamble with some data, and shut down the line again to remove
>> this EMC issue. It seems there is a low power mode, that could be used.
>>
>> Anyone tried something like this?
>>
>> We are using DP83822
>>
>> :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467
>
> In the eighties we had a similar problem in a large industrial plant with PLCs connected to a computer
> Decided to go optical, worked perfectly.
> Like this (have not tried that one):
> https://www.amazon.com/Tripp-Lite-N784-001-ST-Multimode-Converter/dp/B000IAOL84/ref=sr_1_10?keywords=fiber%2Bto%2Bethernet%2Bconverter&qid=1649502290&sr=8-10&th=1erface tings you can buy.
>
The product is just weeks away from final design, so we cannot change to
optical (also, the other end does not accept optical, since it is a
standard switch)

On 09/04/2022 16.14, jlarkin@highlandsniptechnology.com wrote:
> On Sat, 09 Apr 2022 10:59:07 +0200, Klaus Kragelund
> <klauskvik@hotmail.com> wrote:
>
>> Hi
>>
>> I am working on a product that connects to an access point via ethernet 100 Base TX
>> I am having some problems with common mode noise on the ethernet cable, and have been trying all sorts of tricks, nothing help as of now
>>
>> So staring at the signals on the cable, there is a lot of traffic even though we just use it for sub kB/s traffic. The reason for the traffic is the MLT-3 encoding, so even with nothing to transfer, the line is busy as xxxx
>>
>> So it occurred to me, why not just disable the line, and send a preamble with some data, and shut down the line again to remove this EMC issue. It seems there is a low power mode, that could be used.
>>
>> Anyone tried something like this?
>>
>> We are using DP83822
>>
>> :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467
>
> You might go optical, with SFP modules.
>
>
>
The product is just weeks away from final design, so we cannot change to
optical (also, the other end does not accept optical, since it is a
standard switch)

On 09/04/2022 15.47, Don Y wrote:
> On 4/9/2022 5:17 AM, Klaus Kragelund wrote:
>> 09.04.22 11:29, Don Y  wrote:
>>> On 4/9/2022 1:59 AM, Klaus Kragelund wrote:
>>>> I am working on a product that connects to an access point via
>>>> ethernet 100 Base TX
>>>
>>> Most "access points" are *wireless* devices acting as gateways onto a
>>> wired
>>> network.  Are you trying to connect to the wired port of the AP?
>>
>> Yes, this is a wired Ethernet product
>
> So, what is the "access point" to which you refer?
>

Well, I got your point. It is rather a router or switch with LAN access

>>>> I am having some problems with common mode noise on the ethernet
>>>> cable, and have been trying all sorts of tricks, nothing help as of now
>>>>
>>>> So staring at the signals on the cable, there is a lot of traffic
>>>> even though we just use it for sub kB/s traffic. The reason for the
>>>> traffic is the MLT-3 encoding, so even with nothing to transfer, the
>>>> line is busy as xxxx
>>>
>>> Unless you have a point-to-point link, there will almost always be
>>> "traffic"
>>> on the line as many protocols rely on the switch to replicate the
>>> traffic on
>>> all ports for other protocols to function properly.
>>
>> That is a good point, perhaps it's not possible to be sure that this
>> connection is the only one
>
> In general, you can't control:
> - the number and "character" of nodes connected
> - the type/quality/length of cable (incl "homemade" cables)
> - how that cable is routed (wrt mains cables and other noise sources)
> - the make/model/type of switch
> - the nodes that decide to "chat with you"
> - the adherence of other nodes to the correct protocols
> - the benevolence of other nodes
> - the connection/isolation of your device from the above
>
> (connecting to an ethernet comes at some peril)
>
> If you've rolled your own stack, be sure to examine it for the
> numerous vulnerabilities/exploits that "adversaries" may deploy
> against you.
>
> If you've "inherited" a protocol stack, it is wise to make sure you
> understand the implementation, in detail, to be harden against
> likely vulnerabilities.
>
> You can make certain claims about the "requirements" to use your
> device -- but those will likely never be checked by your customers
> and, even if THEY have failed to comply, YOU will be seen as the
> faulty component.
>

The cables are defined in the specification of the product, more for EMC
reasons. We know that some customers might use crappy cables, but that
will then be their own responsibility

You are right in all the other points about the difficulty to control
what is actually hooked up on the other end of our connection

>>> So, you're saying the "idle traffic" is the problem that you want to
>>> eliminate?  Is it's quantity or "frequency" the issue?
>>>
>>> Do you have complete control over the network and the hosts on it?
>>> E.g.,
>>> if your node is "deaf" because the connection is "shut off", then you
>>> have to ensure that it's configuration is baked into the network's
>>> design; so the IP address it is using (while "shut off") won't be
>>> delegated to some other node while your node "isn't watching".
>>>
>>> Otherwise, each time you "reconnect" to the network, you will have to
>>> make sure your presence is known.
>>
>> Yes. I could power it down totally, but I think the reinitualization
>> will take longer than the settle time of the test receiver
>
> You can try an energy efficient switch -- but, there's no guarantee that
> you
> will be deployed with one and no easy way to detect that you are
> operating in
> that environment whereby you can "refuse" to operate (escalating the
> "problem"
> before it becomes an *intermittent* "noise" problem).  And, the problem
> will
> reappear when the link comes back up (which can be at the behest of some
> OTHER node deciding it needs to talk to/at you).
>
> You can disable autonegotiation and force the NIC to use 10BaseT --
> which cuts
> the peak throughput and increases latency but may be adequate for your
> needs.
>

Very interesting, but as you wrote about it might mean that some
customers will be having problems with compatibility. Anyway, would be
interesting to try it out, at least to know the possibilities for coming
products

> You can go a different (i/f) route and employ a media converter to bridge
> to ethernet "past" your device (e.g., optical in your device to converter
> to copper).  Or, even something like a traditional serial port talking to a
> "one port terminal server" acting as a media converter (I have such a
> configuration for my PROM programmer)
>
> Or, you can ask yourself what is *so* unique about your
> design/implementation
> that *it* has this problem where others don't (?)  Are you trying to do
> something particularly sensitive?  Bad layout?  etc.

Yes, the layout is not good (another guy on the team did it, and we
actually didn't do a proper review). And it should be changed before
other hardware solutions are investigated.

And, our design is not unique, a standard design should be able to pass
EMC with little problems, so should ours

Ground plane was routed below the magnetics, so possibly shorting the CM
coil. Termination resistors in wrong places, etc. I was just looking for
a quick fix, SW is free.

I did see a skew between TX_P and TX_N signals, that shouldn't be there,
and which cannot be explained with signal trace differences and
impedance discontinuities. I was more inclined to blame asymmetric
magnetics, but the RX_P and RX_N lines does not have the skew, and when
the line auto negotiates crossover, the skew seem to follow the TX_P and
TX_N lines, not the channel

On Sat, 9 Apr 2022 21:54:53 +0200, Klaus Vestergaard Kragelund
<klauskvik@hotmail.com> wrote:

>On 09/04/2022 16.14, jlarkin@highlandsniptechnology.com wrote:
>> On Sat, 09 Apr 2022 10:59:07 +0200, Klaus Kragelund
>> <klauskvik@hotmail.com> wrote:
>>
>>> Hi
>>>
>>> I am working on a product that connects to an access point via ethernet 100 Base TX
>>> I am having some problems with common mode noise on the ethernet cable, and have been trying all sorts of tricks, nothing help as of now
>>>
>>> So staring at the signals on the cable, there is a lot of traffic even though we just use it for sub kB/s traffic. The reason for the traffic is the MLT-3 encoding, so even with nothing to transfer, the line is busy as xxxx
>>>
>>> So it occurred to me, why not just disable the line, and send a preamble with some data, and shut down the line again to remove this EMC issue. It seems there is a low power mode, that could be used.
>>>
>>> Anyone tried something like this?
>>>
>>> We are using DP83822
>>>
>>> :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467
>>
>> You might go optical, with SFP modules.
>>
>>
>>
>The product is just weeks away from final design, so we cannot change to
>optical (also, the other end does not accept optical, since it is a
>standard switch)

Cat5 to SFP converters are cheap. Maybe you could add those on both
ends.

Biggish switches often have SFP slots too.

--

I yam what I yam - Popeye

On 10-Apr-22 7:13 am, jlarkin@highlandsniptechnology.com wrote:
> On Sat, 9 Apr 2022 21:54:53 +0200, Klaus Vestergaard Kragelund
> <klauskvik@hotmail.com> wrote:
>
>> On 09/04/2022 16.14, jlarkin@highlandsniptechnology.com wrote:
>>> On Sat, 09 Apr 2022 10:59:07 +0200, Klaus Kragelund
>>> <klauskvik@hotmail.com> wrote:
>>>
>>>> Hi
>>>>
>>>> I am working on a product that connects to an access point via ethernet 100 Base TX
>>>> I am having some problems with common mode noise on the ethernet cable, and have been trying all sorts of tricks, nothing help as of now
>>>>
>>>> So staring at the signals on the cable, there is a lot of traffic even though we just use it for sub kB/s traffic. The reason for the traffic is the MLT-3 encoding, so even with nothing to transfer, the line is busy as xxxx
>>>>
>>>> So it occurred to me, why not just disable the line, and send a preamble with some data, and shut down the line again to remove this EMC issue. It seems there is a low power mode, that could be used.
>>>>
>>>> Anyone tried something like this?
>>>>
>>>> We are using DP83822
>>>>
>>>> :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467
>>>
>>> You might go optical, with SFP modules.
>>>
>>>
>>>
>> The product is just weeks away from final design, so we cannot change to
>> optical (also, the other end does not accept optical, since it is a
>> standard switch)
>
> Cat5 to SFP converters are cheap. Maybe you could add those on both
> ends.
>
> Biggish switches often have SFP slots too.
>
>
>

If the noise is originating from poor board layout, then going optical
isn't going to help.

Sylvia

On 4/9/2022 1:09 PM, Klaus Vestergaard Kragelund wrote:
>> You can make certain claims about the "requirements" to use your
>> device -- but those will likely never be checked by your customers
>> and, even if THEY have failed to comply, YOU will be seen as the
>> faulty component.
>
> The cables are defined in the specification of the product, more for EMC
> reasons.

Likely to get product certification (?)

> We know that some customers might use crappy cables, but that will
> then be their own responsibility

But if the cable ends up making a significant difference to the product's
performance (unlikely?), you'll still bear the cost of customer support calls
and some possible "bad feelings" (folks like to blame others).

> You are right in all the other points about the difficulty to control what is
> actually hooked up on the other end of our connection

As well as how those "other" things will behave from the perspective of
your device. E.g., the MS machines on my network are responsible for
almost all of the "idle chatter" -- as they try to perform various discovery
and routing activities.

>>>> So, you're saying the "idle traffic" is the problem that you want to
>>>> eliminate? Is it's quantity or "frequency" the issue?
>>>>
>>>> Do you have complete control over the network and the hosts on it? E.g.,
>>>> if your node is "deaf" because the connection is "shut off", then you
>>>> have to ensure that it's configuration is baked into the network's
>>>> design; so the IP address it is using (while "shut off") won't be
>>>> delegated to some other node while your node "isn't watching".
>>>>
>>>> Otherwise, each time you "reconnect" to the network, you will have to
>>>> make sure your presence is known.
>>>
>>> Yes. I could power it down totally, but I think the reinitualization will
>>> take longer than the settle time of the test receiver
>>
>> You can try an energy efficient switch -- but, there's no guarantee that you
>> will be deployed with one and no easy way to detect that you are operating in
>> that environment whereby you can "refuse" to operate (escalating the "problem"
>> before it becomes an *intermittent* "noise" problem). And, the problem will
>> reappear when the link comes back up (which can be at the behest of some
>> OTHER node deciding it needs to talk to/at you).
>>
>> You can disable autonegotiation and force the NIC to use 10BaseT -- which cuts
>> the peak throughput and increases latency but may be adequate for your needs.
>
> Very interesting, but as you wrote about it might mean that some customers will
> be having problems with compatibility. Anyway, would be interesting to try it
> out, at least to know the possibilities for coming products

You needn't replace the entire fabric with 10BaseT (which would lower overall
performance of the network). Rather, you could selectively define your device
as having a slower i/f and let the elastic store in the switch compensate
for the "speed difference".

Of course, transport delay is increased but if you're expecting any sort of
timeliness guarantees the switch (and "other" traffic that it is managing)
already blows those to hell.

The problem wrt doing anything "different"/unexpected/out-of-the-ordinary is
that it tends to lead to the introduction of configuration options. Which
are just more opportunities for things to get hosed as users poke at options
without understanding their consequences (unless your market is very tech
savvy). E.g., I've had to "fix" many duplex mismatches over the years
for friends/colleagues/clients that didn't understand what the setting did
and tinkered with it in ignorance.

>> You can go a different (i/f) route and employ a media converter to bridge
>> to ethernet "past" your device (e.g., optical in your device to converter
>> to copper). Or, even something like a traditional serial port talking to a
>> "one port terminal server" acting as a media converter (I have such a
>> configuration for my PROM programmer)
>>
>> Or, you can ask yourself what is *so* unique about your design/implementation
>> that *it* has this problem where others don't (?) Are you trying to do
>> something particularly sensitive? Bad layout? etc.
>
> Yes, the layout is not good (another guy on the team did it, and we actually
> didn't do a proper review). And it should be changed before other hardware
> solutions are investigated.

That's why we prototype! :>

> And, our design is not unique, a standard design should be able to pass EMC
> with little problems, so should ours

So, you're not trying to push the bleeding edge in DAS or something...

> Ground plane was routed below the magnetics, so possibly shorting the CM coil.
> Termination resistors in wrong places, etc. I was just looking for a quick fix,
> SW is free.

Well... <frown> The problem then can be perpetuated as folks don't ever
realize the root cause and keep making the same mistake.

Until the "fix" isn't effective in some future situation.

I worked for a company that could never get parts made "to spec" from a
particular vendor. Rather than find another vendor, they simply changed the
rest of the design to reflect that component "as was".

Eventually, ownership of that vendor changed and the new crew started
making the parts "to print"...

Ooops! Now the rest of the assembly wasn't compatible because it had been
reengineered for the out-of-spec component. Luckily, there was enough
institutional knowledge to understand how the problem had come about...

> I did see a skew between TX_P and TX_N signals, that shouldn't be there, and
> which cannot be explained with signal trace differences and impedance
> discontinuities. I was more inclined to blame asymmetric magnetics, but the
> RX_P and RX_N lines does not have the skew, and when the line auto negotiates
> crossover, the skew seem to follow the TX_P and TX_N lines, not the channel

Ummm... are you sure there's nothing wonky in your switch? E.g., its a simple
matter to move to another port. Or, another switch. Just to eliminate another
variable.