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
Halting the ethernet signaling
Started by ●April 9, 2022
Reply by ●April 9, 20222022-04-09
Reply by ●April 9, 20222022-04-09
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
Reply by ●April 9, 20222022-04-09
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 > > > -- > KlausNot 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.
Reply by ●April 9, 20222022-04-09
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
Reply by ●April 9, 20222022-04-09
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.
Reply by ●April 9, 20222022-04-09
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 productSo, 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 oneIn 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 receiverYou 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.
Reply by ●April 9, 20222022-04-09
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-SNLS505SNLS5058467You might go optical, with SFP modules. -- I yam what I yam - Popeye
Reply by ●April 9, 20222022-04-09
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 shieldThat 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 easierI kinda doubt that a SW fix will solve such a problem. Joe Gwinn
Reply by ●April 9, 20222022-04-09
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)
Reply by ●April 9, 20222022-04-09
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)
