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.
Not tried this but there are pause features in ethernet controllers that also may be of use here. I don’t know how long the pause can last but it may be a complement to low power mode.
Do you mean that the ethernet cable is an aggressor in this case? Is this a “standard” magnetically coupled interface? Common mode issues specifically should be a rare issue for ethernet (excluding alien aggressors/coupling). You mentioned 100-base-TX which is surprising. Have you checked that the cabling is CAT6?
I’m not sure I understand your definition of traffic. Ethernet signalling is always busy either in negotiation or link detection (when no packets are being sent). I wouldn’t call this traffic however. If you are using TCP, UDP, etc, then you will also have link-layer-to-network-layer traffic (ARP) on the line. Some implementations periodicallly keep their ARP tables refreshed. Access points may have other discovery protocols that are very chatty. If you have a desktop on the same network (something running Windows, Linux, etc), you’ll be getting all sorts of chatter not related to your device’s connections so long as the PHY has link.
Many (most now, I assume) PHYs support the IEEE power down mode. This makes the PHY inert in terms of the medium being used (e.g. copper) but leaves the management interface operational. This should do what you are looking for from the device perspective however the access point would likely also continue to “buzz” the physical interface.
I’ve been in a situation where I wanted the actual network chatter to be limited on a port that had my device on it. Adjusting the router / access point configuration to disallow broadcast and multicast traffic etc on that port could be another option if the extraneous traffic is an issue. But that could be leaving a gotcha for the future maintainer of the system.
Yes, when we do conducted emission tests at the mains side, all is well. The conducted emission test on the ethernet side with CDN network done at approval body site shows a lot of noise from 15MHz to 30MHz. We do see a difference from our own tests compared to the approval body. With less noise in our own tests. We are using CAT6 cables, and it’s not 100% sure if the cabling at the approval body is CAT6, so that might explain the difference
We are using a standard interface with the PHY->Magnetics->RJ45, with Bob Smith coupling. Layout is not perfect, so I am working down that path also, but a little difficult to do modifications on layout without spinning a new board (one thing the layout guy has done is to place GND plane below the magnetics, and that will most likely short out some of the common mode function of the magnetics)
I am no expert in ethernet, can you explain why that is surprising?
Some of the common mode noise comes from asymmetric of the TX+ and TX- lines. Any asymmetry will result in common mode voltage on the cable. So what I mean by traffic is that I see the channel to look busy, 25MHz bits being sent continuously. That is not from data being sent, but just from the MLT encoding (to avoid a stream of zeroes or ones being send saturating the magnetics)
Even with no data sent, the line is active. So my idea was, if I am not able to solve the noise using the current HW, I could maybe persuade the SW guy to keep the line idle (not just stopping data, but stopping traffic), and then initialize the line and send data when needed. If it could be done, the noise would be reduced by an order of magnitude
The line is point to point, so the idea was just to shut it down, coming alive maybe 10 times per second to check for data. But maybe that is simply not possible, since the time for resync/preamble will probably use the time slot, so no data is sent
That sounds like could work, but as you write then it is probably not 100% compatible or easy to setup