• Halting the ethernet signaling

    From Klaus Kragelund@21:1/5 to All on Sat Apr 9 10:59:07 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Klaus Kragelund@21:1/5 to Klaus Kragelund on Sat Apr 9 11:12:12 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to Klaus Kragelund on Sat Apr 9 02:29:34 2022
    On Saturday, April 9, 2022 at 1:59:15 AM UTC-7, Klaus Kragelund wrote:
    Hi

    I am working on a product that connects to an access point via ethernet 100 Base TX
    I am having some problems with common mode noise on the ethernet cable,...

    Huh? 100baseTX is transformer-coupled, why would common mode be important? Are you doing power-over-Ethernet and having noisy power?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Klaus Kragelund on Sat Apr 9 02:29:41 2022
    On 4/9/2022 1:59 AM, Klaus Kragelund wrote:
    I am working on a product that connects to an access point via ethernet 100 Base TX

    Most "access points" are *wireless* devices acting as gateways onto a wired network. Are you trying to connect to the wired port of the AP?

    I am having some problems with common mode noise on the ethernet cable, and have been trying all sorts of tricks, nothing help as of now

    So staring at the signals on the cable, there is a lot of traffic even though we just use it for sub kB/s traffic. The reason for the traffic is the MLT-3 encoding, so even with nothing to transfer, the line is busy as xxxx

    Unless you have a point-to-point link, there will almost always be "traffic"
    on the line as many protocols rely on the switch to replicate the traffic on all ports for other protocols to function properly.

    E.g., during a DHCP/BOOTP client request, the client *broadcasts* a message to locate any potential DHCP/BOOTP servers on the network. The switch must replicate this message on all of its ports to ensure all hosts in the network get a chance to see it (because the *intended* destination isn't known to the sender)

    Because the client doesn't (yet) have an IP address, any server(s) receiving it's "discovery" broadcast will *broadcast* a reply, *offering* a lease to that client -- indicating a "server ID" for THAT server (multiple servers can attempt to "offer").

    The client will then *broadcast* a "request" -- including an extra ARP to see if any other node has the same (offered) IP address. etc.

    [You can run something like tcpdump/wireshark (even on a wired network) to examine the actual traffic on your network.]

    So it occurred to me, why not just disable the line, and send a preamble with some data, and shut down the line again to remove this EMC issue. It seems there is a low power mode, that could be used.

    So, you're saying the "idle traffic" is the problem that you want to
    eliminate? Is it's quantity or "frequency" the issue?

    Do you have complete control over the network and the hosts on it? E.g.,
    if your node is "deaf" because the connection is "shut off", then you
    have to ensure that it's configuration is baked into the network's
    design; so the IP address it is using (while "shut off") won't be
    delegated to some other node while your node "isn't watching".

    Otherwise, each time you "reconnect" to the network, you will have to
    make sure your presence is known.

    Anyone tried something like this?

    We are using DP83822

    :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From piglet@21:1/5 to Klaus Kragelund on Sat Apr 9 11:00:53 2022
    On 09/04/2022 09:59, Klaus Kragelund wrote:
    Hi

    I am working on a product that connects to an access point via ethernet
    100 Base TX
    I am having some problems with common mode noise on the ethernet cable,
    and have been trying all sorts of tricks, nothing help as of now

    So staring at the signals on the cable, there is a lot of traffic even
    though we just use it for sub kB/s traffic. The reason for the traffic
    is the MLT-3 encoding, so even with nothing to transfer, the line is
    busy as xxxx

    So it occurred to me, why not just disable the line, and send a preamble
    with some data, and shut down the line again to remove this EMC issue.
    It seems there is a low power mode, that could be used.

    Anyone tried something like this?

    We are using DP83822

    :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467




    --
    Klaus

    Ethernet is normally transformer coupled so any common mode noise may be
    down to the transformer interwinding capacity and easily dealt with by
    the traditional ferrite ring over the cable?

    We recently heard of ferrite beads able to work at 50Hz :)

    piglet

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sylvia Else@21:1/5 to Klaus Kragelund on Sat Apr 9 19:32:19 2022
    On 09-Apr-22 7:12 pm, Klaus Kragelund wrote:
    09.04.22 10:59, Klaus Kragelund   wrote:
    Hi

    I am working on a product that connects to an access point via
    ethernet 100 Base TX
    I am having some problems with common mode noise on the ethernet
    cable, and have been trying all sorts of tricks, nothing help as of now

    So staring at the signals on the cable, there is a lot of traffic even
    though we just use it for sub kB/s traffic. The reason for the traffic
    is the MLT-3 encoding, so even with nothing to transfer, the line is
    busy as xxxx

    So it occurred to me, why not just disable the line, and send a
    preamble with some data, and shut down the line again to remove this
    EMC issue. It seems there is a low power mode, that could be used.

    Anyone tried something like this?

    We are using DP83822

    :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467



    The chip supports EEE mode https://www.juniper.net/documentation/us/en/software/junos/interfaces-ethernet-switches/topics/topic-map/switches-interface-eee.html#:~:text=EEE%20uses%20a%20signaling%20protocol,when%20there%20is%20no%20traffic.





    --
    Klaus

    How is the common mode noise causing you a problem?

    Sylvia.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tauno Voipio@21:1/5 to Klaus Kragelund on Sat Apr 9 13:59:18 2022
    On 9.4.22 11.59, Klaus Kragelund wrote:
    Hi

    I am working on a product that connects to an access point via ethernet
    100 Base TX
    I am having some problems with common mode noise on the ethernet cable,
    and have been trying all sorts of tricks, nothing help as of now

    So staring at the signals on the cable, there is a lot of traffic even
    though we just use it for sub kB/s traffic. The reason for the traffic
    is the MLT-3 encoding, so even with nothing to transfer, the line is
    busy as xxxx

    So it occurred to me, why not just disable the line, and send a preamble
    with some data, and shut down the line again to remove this EMC issue.
    It seems there is a low power mode, that could be used.

    Anyone tried something like this?

    We are using DP83822

    :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467




    --
    Klaus


    100BaseTX sends idle signals all the time when there is nothing else to
    send.

    If you have access to the switch at the other end of the link or the configuration of the DP83822, force the link to 10BaseT to stop the
    idles. There will still be link pulses, but less often.

    --

    -TV

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to klauskvik@hotmail.com on Sat Apr 9 11:07:37 2022
    On a sunny day (Sat, 09 Apr 2022 10:59:07 +0200) it happened Klaus Kragelund <klauskvik@hotmail.com> wrote in <tscheppe.1ui5uq8q91brg@nntp.aioe.org>:

    Hi

    I am working on a product that connects to an access point via ethernet 100 Base TX
    I am having some problems with common mode noise on the ethernet cable, and have been trying all sorts of tricks, nothing help
    as of now

    So staring at the signals on the cable, there is a lot of traffic even though we just use it for sub kB/s traffic. The reason
    for the traffic is the MLT-3 encoding, so even with nothing to transfer, the line is busy as xxxx

    So it occurred to me, why not just disable the line, and send a preamble with some data, and shut down the line again to remove
    this EMC issue. It seems there is a low power mode, that could be used.

    Anyone tried something like this?

    We are using DP83822

    :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467

    In the eighties we had a similar problem in a large industrial plant with PLCs connected to a computer
    Decided to go optical, worked perfectly.
    Like this (have not tried that one):
    https://www.amazon.com/Tripp-Lite-N784-001-ST-Multimode-Converter/dp/B000IAOL84/ref=sr_1_10?keywords=fiber%2Bto%2Bethernet%2Bconverter&qid=1649502290&sr=8-10&th=1erface tings you can buy.




    --
    Klaus


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Klaus Kragelund@21:1/5 to Sylvia Else on Sat Apr 9 14:10:34 2022
    09.04.22 11:32, Sylvia Else wrote:
    On 09-Apr-22 7:12 pm, Klaus Kragelund wrote:
    09.04.22 10:59, Klaus Kragelund wrote:
    Hi

    I am working on a product that connects to an access point via
    ethernet 100 Base TX
    I am having some problems with common mode noise on the ethernet
    cable, and have been trying all sorts of tricks, nothing help as of now

    So staring at the signals on the cable, there is a lot of traffic even
    though we just use it for sub kB/s traffic. The reason for the traffic
    is the MLT-3 encoding, so even with nothing to transfer, the line is
    busy as xxxx

    So it occurred to me, why not just disable the line, and send a
    preamble with some data, and shut down the line again to remove this
    EMC issue. It seems there is a low power mode, that could be used.

    Anyone tried something like this?

    We are using DP83822

    :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467



    The chip supports EEE mode
    https://www.juniper.net/documentation/us/en/software/junos/interfaces-ethernet-switches/topics/topic-map/switches-interface-eee.html#:~:text=EEE%20uses%20a%20signaling%20protocol,when%20there%20is%20no%20traffic.





    --
    Klaus

    How is the common mode noise causing you a problem?

    I am seeing assymetric waveforms on TD+ and TD-, so the resultant addition if the signals results in a non zero voltage on the line.

    Ethernet compliance allows for 50mV, and I am seeking a lot of noise above 10MHz in the conducted ethernet tesrs
    .
    It is possible that the cause is poor layout and or non optimal cable shield

    I could spend more time on testing and interate the PCB, but a SW mod is a little eas


    --
    Klaus

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Klaus Kragelund@21:1/5 to All on Sat Apr 9 14:12:12 2022
    09.04.22 11:29, whit3rd wrote:
    On Saturday, April 9, 2022 at 1:59:15 AM UTC-7, Klaus Kragelund wrote:
    Hi

    I am working on a product that connects to an access point via ethernet 100 Base TX
    I am having some problems with common mode noise on the ethernet cable,...

    Huh? 100baseTX is transformer-coupled, why would common mode be important? >Are you doing power-over-Ethernet and having noisy power?
    It is transformer coupled including a CM transformer, but assymetry of the MDI signal priduces common node noise

    --
    Klaus

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sylvia Else@21:1/5 to Klaus Kragelund on Sat Apr 9 22:27:24 2022
    On 09-Apr-22 10:10 pm, Klaus Kragelund wrote:
    09.04.22 11:32, Sylvia Else  wrote:
    On 09-Apr-22 7:12 pm, Klaus Kragelund wrote:
    09.04.22 10:59, Klaus Kragelund�� wrote:
    Hi

    I am working on a product that connects to an access point via
    ethernet 100 Base TX
    I am having some problems with common mode noise on the ethernet
    cable, and have been trying all sorts of tricks, nothing help as of now >>>>
    So staring at the signals on the cable, there is a lot of traffic
    even though we just use it for sub kB/s traffic. The reason for the
    traffic is the MLT-3 encoding, so even with nothing to transfer, the
    line is busy as xxxx

    So it occurred to me, why not just disable the line, and send a
    preamble with some data, and shut down the line again to remove this
    EMC issue. It seems there is a low power mode, that could be used.

    Anyone tried something like this?

    We are using DP83822

    :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467



    The chip supports EEE mode
    https://www.juniper.net/documentation/us/en/software/junos/interfaces-ethernet-switches/topics/topic-map/switches-interface-eee.html#:~:text=EEE%20uses%20a%20signaling%20protocol,when%20there%20is%20no%20traffic.





    --
    Klaus

    How is the common mode noise causing you a problem?

    I am seeing assymetric waveforms on TD+ and TD-, so the resultant
    addition if the signals results in a non zero voltage on the line.
    Ethernet compliance allows for 50mV, and I am seeking a lot of noise
    above 10MHz in the conducted ethernet tesrs
    . It is possible that the cause is poor layout and or non optimal cable shield

    I could spend more time on testing and interate the PCB, but a SW mod is
    a little eas


    --
    Klaus

    Not common mode, then.

    I don't see how disabling the line, whatever that involves, is going to
    help. The noise will still be there when the line is enabled to transmit
    data.

    Sylvia.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Klaus Kragelund@21:1/5 to Don Y on Sat Apr 9 14:17:33 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Klaus Kragelund@21:1/5 to piglet on Sat Apr 9 14:20:48 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Klaus Kragelund@21:1/5 to Tauno Voipio on Sat Apr 9 14:37:04 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Brown@21:1/5 to Klaus Kragelund on Sat Apr 9 15:34:15 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Klaus Kragelund on Sat Apr 9 06:47:17 2022
    On 4/9/2022 5:17 AM, Klaus Kragelund wrote:
    09.04.22 11:29, Don Y wrote:
    On 4/9/2022 1:59 AM, Klaus Kragelund wrote:
    I am working on a product that connects to an access point via ethernet 100 >>> Base TX

    Most "access points" are *wireless* devices acting as gateways onto a wired >> network. Are you trying to connect to the wired port of the AP?

    Yes, this is a wired Ethernet product

    So, what is the "access point" to which you refer?

    I am having some problems with common mode noise on the ethernet cable, and >>> have been trying all sorts of tricks, nothing help as of now

    So staring at the signals on the cable, there is a lot of traffic even
    though we just use it for sub kB/s traffic. The reason for the traffic is >>> the MLT-3 encoding, so even with nothing to transfer, the line is busy as xxxx

    Unless you have a point-to-point link, there will almost always be "traffic" >> on the line as many protocols rely on the switch to replicate the traffic on >> all ports for other protocols to function properly.

    That is a good point, perhaps it's not possible to be sure that this connection
    is the only one

    In general, you can't control:
    - the number and "character" of nodes connected
    - the type/quality/length of cable (incl "homemade" cables)
    - how that cable is routed (wrt mains cables and other noise sources)
    - the make/model/type of switch
    - the nodes that decide to "chat with you"
    - the adherence of other nodes to the correct protocols
    - the benevolence of other nodes
    - the connection/isolation of your device from the above

    (connecting to an ethernet comes at some peril)

    If you've rolled your own stack, be sure to examine it for the
    numerous vulnerabilities/exploits that "adversaries" may deploy
    against you.

    If you've "inherited" a protocol stack, it is wise to make sure you
    understand the implementation, in detail, to be harden against
    likely vulnerabilities.

    You can make certain claims about the "requirements" to use your
    device -- but those will likely never be checked by your customers
    and, even if THEY have failed to comply, YOU will be seen as the
    faulty component.

    So, you're saying the "idle traffic" is the problem that you want to
    eliminate? Is it's quantity or "frequency" the issue?

    Do you have complete control over the network and the hosts on it? E.g.,
    if your node is "deaf" because the connection is "shut off", then you
    have to ensure that it's configuration is baked into the network's
    design; so the IP address it is using (while "shut off") won't be
    delegated to some other node while your node "isn't watching".

    Otherwise, each time you "reconnect" to the network, you will have to
    make sure your presence is known.

    Yes. I could power it down totally, but I think the reinitualization will take
    longer than the settle time of the test receiver

    You can try an energy efficient switch -- but, there's no guarantee that you will be deployed with one and no easy way to detect that you are operating in that environment whereby you can "refuse" to operate (escalating the "problem" before it becomes an *intermittent* "noise" problem). And, the problem will reappear when the link comes back up (which can be at the behest of some
    OTHER node deciding it needs to talk to/at you).

    You can disable autonegotiation and force the NIC to use 10BaseT -- which cuts the peak throughput and increases latency but may be adequate for your needs.

    You can go a different (i/f) route and employ a media converter to bridge
    to ethernet "past" your device (e.g., optical in your device to converter
    to copper). Or, even something like a traditional serial port talking to a "one port terminal server" acting as a media converter (I have such a configuration for my PROM programmer)

    Or, you can ask yourself what is *so* unique about your design/implementation that *it* has this problem where others don't (?) Are you trying to do something particularly sensitive? Bad layout? etc.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to klauskvik@hotmail.com on Sat Apr 9 07:14:13 2022
    On Sat, 09 Apr 2022 10:59:07 +0200, Klaus Kragelund
    <klauskvik@hotmail.com> wrote:

    Hi

    I am working on a product that connects to an access point via ethernet 100 Base TX
    I am having some problems with common mode noise on the ethernet cable, and have been trying all sorts of tricks, nothing help as of now

    So staring at the signals on the cable, there is a lot of traffic even though we just use it for sub kB/s traffic. The reason for the traffic is the MLT-3 encoding, so even with nothing to transfer, the line is busy as xxxx

    So it occurred to me, why not just disable the line, and send a preamble with some data, and shut down the line again to remove this EMC issue. It seems there is a low power mode, that could be used.

    Anyone tried something like this?

    We are using DP83822

    :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467

    You might go optical, with SFP modules.



    --

    I yam what I yam - Popeye

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to klauskvik@hotmail.com on Sat Apr 9 12:44:31 2022
    On Sat, 09 Apr 2022 14:10:34 +0200, Klaus Kragelund
    <klauskvik@hotmail.com> wrote:

    09.04.22 11:32, Sylvia Else wrote:
    On 09-Apr-22 7:12 pm, Klaus Kragelund wrote:
    09.04.22 10:59, Klaus Kragelund wrote:
    Hi

    I am working on a product that connects to an access point via
    ethernet 100 Base TX
    I am having some problems with common mode noise on the ethernet
    cable, and have been trying all sorts of tricks, nothing help as of now >>>>
    So staring at the signals on the cable, there is a lot of traffic even >>>> though we just use it for sub kB/s traffic. The reason for the traffic >>>> is the MLT-3 encoding, so even with nothing to transfer, the line is
    busy as xxxx

    So it occurred to me, why not just disable the line, and send a
    preamble with some data, and shut down the line again to remove this
    EMC issue. It seems there is a low power mode, that could be used.

    Anyone tried something like this?

    We are using DP83822

    :https://www.ti.com/document-viewer/DP83822I/datasheet/GUID-024DD3DE-0EAA-4F18-9EF3-9C0B37F9613C#TITLE-SNLS505SNLS5058467



    The chip supports EEE mode
    https://www.juniper.net/documentation/us/en/software/junos/interfaces-ethernet-switches/topics/topic-map/switches-interface-eee.html#:~:text=EEE%20uses%20a%20signaling%20protocol,when%20there%20is%20no%20traffic.





    --
    Klaus

    How is the common mode noise causing you a problem?

    I am seeing asymmetric waveforms on TD+ and TD-, so the resultant addition if the signals results in a non zero voltage on the line.

    Ethernet compliance allows for 50mV, and I am seeking a lot of noise above 10MHz in the conducted ethernet tesrs
    .
    It is possible that the cause is poor layout and or non optimal cable shield

    That would be my guess, but only after determining that the receiver transformer coupling is in fact achieving galvanic isolation, or
    ground currents in the facility may cause the receivers to stray out
    of their allowed common-mode DC voltage offset range. This can be
    directly tested using a battery and a potentiometer.

    The cable must be twisted pair with at least a specified number of
    twists per foot, and although not required, may and maybe should be
    shielded. These should together reduce asymmetry.

    And, as another has mentioned, the PoE supply may be contaminating
    things. Again, this is directly testable. If this is happening, a
    cable shield may help.


    I could spend more time on testing and interate the PCB, but a SW mod is a little easier

    I kinda doubt that a SW fix will solve such a problem.

    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Joe Gwinn on Sat Apr 9 10:39:03 2022
    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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Klaus Vestergaard Kragelund@21:1/5 to Jan Panteltje on Sat Apr 9 21:54:37 2022
    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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Klaus Vestergaard Kragelund@21:1/5 to jlarkin@highlandsniptechnology.com on Sat Apr 9 21:54:53 2022
    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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Klaus Vestergaard Kragelund@21:1/5 to Don Y on Sat Apr 9 22:09:01 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to klauskvik@hotmail.com on Sat Apr 9 14:13:25 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sylvia Else@21:1/5 to jlarkin@highlandsniptechnology.com on Sun Apr 10 20:07:20 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Klaus Vestergaard Kragelund on Sun Apr 10 06:29:49 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to All on Sun Apr 10 07:16:46 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arie de Muijnck@21:1/5 to Klaus Kragelund on Mon Apr 11 10:25:26 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Walliker@21:1/5 to Arie de Muijnck on Mon Apr 11 01:53:30 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sylvia Else@21:1/5 to Klaus Kragelund on Mon Apr 11 19:00:16 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arie de Muijnck@21:1/5 to John Walliker on Mon Apr 11 12:07:57 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Klaus Vestergaard Kragelund@21:1/5 to Arie de Muijnck on Sat Apr 16 00:51:52 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Klaus Vestergaard Kragelund@21:1/5 to John Walliker on Sat Apr 16 00:53:12 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Klaus Vestergaard Kragelund@21:1/5 to Sylvia Else on Sat Apr 16 00:55:18 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Les Cargill@21:1/5 to Klaus Kragelund on Thu Jun 16 19:51:12 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)