> 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
Reply by Klaus Vestergaard Kragelund●April 15, 20222022-04-15
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
Reply by Klaus Vestergaard Kragelund●April 15, 20222022-04-15
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
Reply by Klaus Vestergaard Kragelund●April 15, 20222022-04-15
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
Reply by Arie de Muijnck●April 11, 20222022-04-11
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
Reply by Sylvia Else●April 11, 20222022-04-11
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.
Reply by John Walliker●April 11, 20222022-04-11
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
Reply by Arie de Muijnck●April 11, 20222022-04-11
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
>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
Reply by Don Y●April 10, 20222022-04-10
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.