Halting the ethernet signaling...

[Klaus Kragelund]

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

 

[Klaus Kragelund]

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

 

[whit3rd]

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?

 

[Don Y]

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

 

[Sylvia Else]

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.

 

[piglet]

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

 

[Tauno Voipio]

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

 

[Jan Panteltje]

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

 

[Klaus Kragelund]

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

 

[Klaus Kragelund]

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

 

[Klaus Kragelund]

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

 

[Klaus Kragelund]

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

 

[Sylvia Else]

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.

 

[Klaus Kragelund]

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

 

[David Brown]

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.

 

[Don Y]

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.

 

[server]

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

 

[Joe Gwinn]

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

 

[Don Y]

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)

 

[Klaus Vestergaard Kragelund]

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)