Halting the ethernet signaling...

[Klaus Vestergaard Kragelund]

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)

 

[Klaus Vestergaard Kragelund]

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

 

[server]

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

 

[Sylvia Else]

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

 

[Don Y]

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.

 

[server]

On Sun, 10 Apr 2022 20:07:20 +1000, Sylvia Else <sylvia@email.invalid>
wrote:

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

True, but the complaint was \"common mode noise on the ethernet cable\",
which fiber could fix.

SFPs are astounding technology for the price. 10 gbit modules are
under $20 from Amazon. I\'d want maybe $2000 to make one.

We are using a Micrel laser driver chip that was apparently designed
to go inside an SFP module. We\'re paying about $10 for it. And that\'s
just one part of what in an SFP.

https://tinyurl.com/2wwty2km

plus there\'s the board, and lots of metal bits.



--

I yam what I yam - Popeye

 

[Arie de Muijnck]

On 2022-04-09 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

--
Klaus

Hi Klaus,

I could not find this info in the thread, but:

You DO use CAT 5 SFTP instead of the noise radiating UTP type?
And with properly terminated connectors (the shield fully
connected, not just through a pigtal wire?

Products are EMC (CE) qualified using \'the recommended cable\'.
Recommending CAT5 SFTP (or better) to the end user allows you to use
SFTP during EMC testing. What the customer actually uses is his
responsibility.

I noticed this type of problems when my UTP cabled network was radiating
so much noise that it affected my measurements. Replacing everything
with SFTP solved a lot of problems.

Arie

 

[John Walliker]

On Monday, 11 April 2022 at 09:25:32 UTC+1, Arie de Muijnck wrote:

On 2022-04-09 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

--
Klaus


Hi Klaus,

I could not find this info in the thread, but:

You DO use CAT 5 SFTP instead of the noise radiating UTP type?
And with properly terminated connectors (the shield fully
connected, not just through a pigtal wire?

Products are EMC (CE) qualified using \'the recommended cable\'.
Recommending CAT5 SFTP (or better) to the end user allows you to use
SFTP during EMC testing. What the customer actually uses is his
responsibility.

I noticed this type of problems when my UTP cabled network was radiating
so much noise that it affected my measurements. Replacing everything
with SFTP solved a lot of problems.

Arie

But it can introduce some new ones as it introduces the possibility of
ground loops (as does PoE). Some, but not all devices have capacitors
in series with the shield connection.
Last time I was at an EMC test lab all the ethernet cables hanging on
the wall for customers to use were shielded. I was told that most
customers preferred to use shielded cables for testing. I brought my
own unshielded cables as we were able to pass (just) with unshielded.
I did come across some unshielded patch cables that worked fine but
radiated badly at 125MHz. Swapping them for alternatives solved the
problem, so do try substituting patch cables if you are having difficulties.

John

 

[Sylvia Else]

On 09-Apr-22 6:59 pm, 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

Obvious questions to ask are:

1) Does the noise go away if the board is not powered?

2) Does the noise go away if the other end of the cable is disconnected,
or is connected to a different router?

3) Does the noise go away if you use a different short cable plugged
into a nearby router?

Sylvia.

 

[Arie de Muijnck]

On 2022-04-11 10:53, John Walliker wrote:

On Monday, 11 April 2022 at 09:25:32 UTC+1, Arie de Muijnck wrote:
On 2022-04-09 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

--
Klaus


Hi Klaus,

I could not find this info in the thread, but:

You DO use CAT 5 SFTP instead of the noise radiating UTP type?
And with properly terminated connectors (the shield fully
connected, not just through a pigtal wire?

Products are EMC (CE) qualified using \'the recommended cable\'.
Recommending CAT5 SFTP (or better) to the end user allows you to use
SFTP during EMC testing. What the customer actually uses is his
responsibility.

I noticed this type of problems when my UTP cabled network was radiating
so much noise that it affected my measurements. Replacing everything
with SFTP solved a lot of problems.

Arie

But it can introduce some new ones as it introduces the possibility of
ground loops (as does PoE). Some, but not all devices have capacitors
in series with the shield connection.
Last time I was at an EMC test lab all the ethernet cables hanging on
the wall for customers to use were shielded. I was told that most
customers preferred to use shielded cables for testing. I brought my
own unshielded cables as we were able to pass (just) with unshielded.
I did come across some unshielded patch cables that worked fine but
radiated badly at 125MHz. Swapping them for alternatives solved the
problem, so do try substituting patch cables if you are having difficulties.

John

Ground loops can be a real problem, but PoE should NOT cause it because
it MUST be floating on the PD (powered device) end. Lots of PSE side
equipment has the + side grounded and switch in the - side!
See IEEE std 802.3 section 33.4.1: PD, Isolation, 1500V rms test.

A famous error here in the Netherlands was made by a yacht builder. The
functional test for the PoE powered WiFi base stations in each cabin was
only made after all (very expensive) wood ceilings were put in place.
The WiFi stations were not isolated and connected to the ship\'s metal
structure. All ceilings had to be re-opened and partly replaced.

Arie

 

[Klaus Vestergaard Kragelund]

On 11/04/2022 10.25, Arie de Muijnck wrote:

On 2022-04-09 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

--
Klaus


Hi Klaus,

I could not find this info in the thread, but:

     You DO use CAT 5 SFTP instead of the noise radiating UTP type?
     And with properly terminated connectors (the shield fully
     connected, not just through a pigtal wire?

Products are EMC (CE) qualified using \'the recommended cable\'.
Recommending CAT5 SFTP (or better) to the end user allows you to use
SFTP during EMC testing. What the customer actually uses is his
responsibility.

I noticed this type of problems when my UTP cabled network was radiating
so much noise that it affected my measurements. Replacing everything
with SFTP solved a lot of problems.

Yes, we are using the shielded cable CAT5. Tests done here and in a
notified body did not match up, and we have narrowed it down to them not
using the correct cable, just as you mention

 

[Klaus Vestergaard Kragelund]

On 11/04/2022 10.53, John Walliker wrote:

On Monday, 11 April 2022 at 09:25:32 UTC+1, Arie de Muijnck wrote:
On 2022-04-09 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

--
Klaus


Hi Klaus,

I could not find this info in the thread, but:

You DO use CAT 5 SFTP instead of the noise radiating UTP type?
And with properly terminated connectors (the shield fully
connected, not just through a pigtal wire?

Products are EMC (CE) qualified using \'the recommended cable\'.
Recommending CAT5 SFTP (or better) to the end user allows you to use
SFTP during EMC testing. What the customer actually uses is his
responsibility.

I noticed this type of problems when my UTP cabled network was radiating
so much noise that it affected my measurements. Replacing everything
with SFTP solved a lot of problems.

Arie

But it can introduce some new ones as it introduces the possibility of
ground loops (as does PoE). Some, but not all devices have capacitors
in series with the shield connection.
Last time I was at an EMC test lab all the ethernet cables hanging on
the wall for customers to use were shielded. I was told that most
customers preferred to use shielded cables for testing. I brought my
own unshielded cables as we were able to pass (just) with unshielded.
I did come across some unshielded patch cables that worked fine but
radiated badly at 125MHz. Swapping them for alternatives solved the
problem, so do try substituting patch cables if you are having difficulties.

John

In our system we follow standard procedure, that is to have a
transformer to isolate the system from the ethernet line, and then a
1500V rated capacitor to earth

 

[Klaus Vestergaard Kragelund]

On 11/04/2022 11.00, Sylvia Else wrote:

On 09-Apr-22 6:59 pm, 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

Obvious questions to ask are:

1) Does the noise go away if the board is not powered?

Yes, did test that

2) Does the noise go away if the other end of the cable is disconnected,
or is connected to a different router?

Yes, also

3) Does the noise go away if you use a different short cable plugged
into a nearby router?

Sadly no, by I do see a small difference in the resonance peak frequency
when using longer ethernet cable. If I use a longer mains cable, I can
move the mains resonance at 30MHz radiated tests easily

 

[Les Cargill]

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

Go optical. I haven\'t tested this, so it\'s here only as an idea starter:

https://www.fs.com/products/96396.html?country=US&currency=USD&languages=English&paid=google_shopping&gclid=CjwKCAjwqauVBhBGEiwAXOepkQjO0zc0YTKm3zO27fEChydyUJUJfkKkDgDHz_C7MCRvcD9-kRGbZBoCbeoQAvD_BwE

You may still get emitted energy in harmonics of 25 MHz because of the
interface to the PHY chip. I guess it\'s MII these days.

Or:

> we just use it for sub kB/s traffic.

Perhaps use RS485/RS422. Even TCP/IP over those can work with some work.

--
Les Cargill