Halting the ethernet signaling

The chip supports EEE mode

>

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

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?

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, 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.

How is the common mode noise causing you a problem?

Sylvia.

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

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.

On a sunny day (Sat, 09 Apr 2022 10:59:07 +0200) it happened Klaus Kragelund snipped-for-privacy@hotmail.com wrote in snipped-for-privacy@nntp.aioe.org>:

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):

tings you can buy.

Yes, this is a wired Ethernet product

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

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

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

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.

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.

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

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.

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.

You might go optical, with SFP modules.

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 kinda doubt that a SW fix will solve such a problem.

Joe Gwinn

But you can't count on your customer using "quality cables" -- even if you supply them! <frown>

Que? I don't see PoE being used, here.

*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)

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)

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)