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)
Halting the ethernet signaling
Started by ●April 9, 2022
Reply by ●April 9, 20222022-04-09
Reply by ●April 9, 20222022-04-09
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
Reply by ●April 9, 20222022-04-09
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
Reply by ●April 10, 20222022-04-10
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
Reply by ●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 responsibilityBut 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 connectionAs 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 productsYou 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 oursSo, 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 channelUmmm... 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.
Reply by ●April 10, 20222022-04-10
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. > >SylviaTrue, 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 ●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 > > -- > KlausHi 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
Reply by ●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. > > ArieBut 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 ●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 > > > > > -- > KlausObvious 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 ●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. > > JohnGround 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
