RE: New thread on EMI
Sorry for not being able to help you, and provided the information which was
not what you asked.
I apologize for that.
Since we are not discussing a specific design, I just point out that the
clock and associated signals are usually the main source of EMI headache. A
single signal, IDLE, is usually not a main EMI headache.
We just got the EMI certification on one of our GbE equipment test by Unisys
EMI laboratory in Pennsylvania. I reviewed the EMI test report, and it
showed both during "IDLE time" and "data transmitting time", the EMI
emission levels are so low (near 10 dBuv/m out of 40 dBuv/m maximum limit),
that the data are almost un-readable form the chart.
In past, I developed many networking equipment which all passed EMI test
without any big deal, and I never experienced a single encoded data pattern
to cause a major EMI problem. So again, this time we passed another EMI
test. It is pretty much a routine.
I am a little bit incomprehensive about why "IDLE" became such a big deal in
our 10GbE reflector, just based on one engineering report. Assume the
additional 6 dB from IDLE was an accurate data reported, it does not mean
anything unless we know where is the base-line EMI emission level. If it is
way down, as in my case, even additional 20 dB does not mean a lot.
As I mentioned before, EMI has to do with the total equipment EMI emission
level measured on the final product by a certified EMI laboratory, otherwise
the data are only good for relative comparison, but no absolute value.
We should remind ourselves, Ethernet is very cost-effective which is the
reason Ethernet has over 85% of LAN market share. I hope we do not keep
adding unnecessary cost here, and there to make it expensive to cost
ourselves out of market.
I also add a brief comment on each of your paragraphs.
I don't agree with this in whole, only in part. And we had a disconnect on
really was asking when I started this thread.
> Comparing to the amplitude of the EMI emissions generated by multiple
> and data lines, the EMI emission from an IDLE signal is small. If an EMI
> design can satisfy clocks/datas, then IDLE is not a problem.
> You should take a look at the actual EMI test report to appreciate it.
> Ed Chang
The test report, as Dan Dove hinted at in earlier replies, will show the
the harmonics from the clocks, common mode noise concerns, logic edge rates
each kind of logic family used, and, of course, the effects from any
communications channel. (oh yeah - and perhaps your favorite TV/radio
) And as Dan hinted at, proper design technique will reduce everything very
nicely from the 'contributer list'. However, the channel, in our case
has had some nasty components that escape as part of the stream and not
from clocks - careful control of the spectrum analyzer and packet content
you determine this.
COMMENT: As I said, the EMI test data should be provided by a certified EMI
laboratory, otherwise they are only good for relative discussion. The
reflection from a ordinary room will mislead the data. I can not comment on
Dan's data, because I am not familiar his setup.
Look at 100tx. There are five components that escape via the port that are
clock or clock harmonic related. These are very nasty and climb quite
port count. So I don't agree that the IDLE is not a problem. We can agree
COMMENT: Your 100tx is a specific product which has many ports. Besides,
it is a twisted paire cable which has worse EMI problems than the "optical
link" we are discussing. The EMI design happened to be not taking care of
your unique multiport emission problem. I am not familiar with your 100xt;
therefore, I can not comment why? However, I think it is unfair to use your
100tx problem to conclude a IDLE problem at 10GbE 8B/10B coded link.
My intent for this thread was you indicated to Pat Thaler that there were
patterns that were worse then idle. My question was do you have data of
network traffic that suggests a percent of the traffic has a higher
to EMI then the idle and what percent is it / what is the packet content
could cause this? If the percentage is very low, then perhaps the idle
content is the only area in need of change.
COMMENT: Sorry I did not respond the answers you were looking for.
In our EMI test, we provided all IDLE continuously and random data patterns
which were requested by the EMI laboratory. The emission level was so low
in both cases, we do not bother to spend too much time on it. Therefore, I
do not have any particular 8B/10B data pattern which can cause worse
emission than IDLE. However, in general, I experienced a lot of clock
I ask the question because my fear is solving the idle issue may case some
area within the coding stream to show as the offending contributer when
as a percent of data traffic. I want to stay a head of the game. As you
indicated, EMI is best dealt with at the design, not on the production line
COMMENT: Unfortunately, the test setup during your development at your
engineering laboratory, and the final product with final enclosure setup at
the certified EMI laboratory will yield quite a different EMI data which are
not directly correlated each other. Every time your product has EMI
problem, you have to complete the product, then send to the certified EMI
lab to test again. There is no easy way out. Only your successful EMI
experience will help you.
Edward S. Chang
NetWorth Technologies, Inc.