Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [10GBT] More on the PAM12 emissions



>
> The numbers that we were able to put our hands on for FCC Part 15
indicated a _minimum_ resolution BW of 100 kHz.
> ["Introduction to Electromagnetic Compatibility", Clayton R. Paul.] From a
quick web search, it appears that this
> number may now be specified as 120 kHz, but were not able to quickly
locate a primary reference.
>

Hi Glenn,
  FYI, the 120kHz bandwidth you mention is correct and is specified in the
ISO/IEC 1/SC 25/WG 3 "Customer Premises Cabling" document that Alan Flatman
submitted to the group last meeting (section 5.1.1).

- Scott

Dr. Scott Powell
Senior Manager, Ethernet PHYs
Broadcom Corp.
(949)926-5105
spowell@broadcom.com


-----Original Message-----
From: stds-802-3-10gbt@ieee.org [mailto:stds-802-3-10gbt@ieee.org] On Behalf
Of Glenn Golden
Sent: Monday, July 26, 2004 3:26 PM
To: STDS-802-3-10GBT@listserv.ieee.org
Subject: Re: [10GBT] More on the PAM12 emissions


Sailesh Rao writes:
>
> 1. Please run glenn(128) and you will see the PSD shape you expect. 2.
> Next, please run glenn(65536) and you will see the PSD discretize and
> shoot up by about 50dB because the same pattern is being sent over and
> over.
>

Yes, and every time you double the parameter, it will "shoot up" another 6
dB. So there's really no reason to stop at 50: You can be as alarmist as you
like (as you've done in your more recent posting, showing the FAS after
422224 symbols being 10 dB above the data):  Using your program, if you've
got enough time and RAM, you can make those peaks 100 dB above the average,
200 dB, anything you want.

If the FCC/CISPR certified equipment using your program, the EMI margin
would be negative infinity.  You couldn't certify any equipment at all,
regardless of your transmit level.  No matter how much you reduced the
transmit power, it would always be possible choose a parameter to your
program such that the peaks of any periodic signal, no matter how long the
period, would always rise above any limit line you happen to set.

If you change the frame period from 4224 symbols to 4224 years, you'd still
have the same problem.  Every modem that uses a scrambler would fail, the
scramblers are all periodic if you wait long enough.  As you even say
yourself,

>
> The data PSD won't help if your frame start PSD keeps shooting up
> uncontrollably.
>

That's right. If your program were an accurate model of a real-world
spectrum analysis procedure, the spectral lines of any periodic signal
component in any piece of equipment, regardless of the period, would shoot
up uncontrollably, and no one would be able to certify any equipment at all.

Clearly something is wrong with this. Let's have a look at what it is.

First, as Jose pointed out, your program does not model anything except the
FAS, in isolation.  There's no PAM-12 customer data.  You transmit the FAS,
wait 120 symbol periods (during which time you transmit nothing) then
transmit the FAS again, and so on. So, one way to improve your program would
be to include the customer data, which, after all, does comprise 4216/4224 =
99.8% of the signal energy. You could then also average over many frames of
length equal to your parameter size. That way, you could explicitly see the
relationship between the FAS carriers and the data spectrum.  If you did
that, then you'd see that every doubling of your parameter increases the FAS
carriers by 6 dB and the data average power by 3 dB.

Another feature of your program is that the size of the parameter (128,
65535, etc.) determines the length of the FFT.  So, as the parameter
increases, so does the resolution bandwidth. By increasing the resolution
BW, you can amplify the periodic components to any degree that you like
relative to the  random data, since the former adds coherently and the
latter does not. In effect, the ratio of the FFT size to the frame length is
a processing gain, amplifying the periodic component by that ratio.

But in order to assess EMI in the real world, it's necessary to limit the
resolution BW to some value that makes sense for the purpose at hand.  When
you plug in a fixed resolution BW, then the ratio of the FAS to the data
average is limited by the corresponding processing gain, and you can make
real world measurements which are meaningful.

The numbers that we were able to put our hands on for FCC Part 15 indicated
a _minimum_ resolution BW of 100 kHz.  ["Introduction to Electromagnetic
Compatibility", Clayton R. Paul.] From a quick web search, it appears that
this number may now be specified as 120 kHz, but were not able to quickly
locate a primary reference.

In your most recent posting, you used 422224 symbols (I assume you meant
422400 = 4224*100, but it doesn't matter much).  Thus, your implicit
resolution BW was 825E6/422224 = 2 kHz, almost two orders of magnitude
narrower than the measurement standard. That's an error of 17 dB in
processing gain.

In addition, you got the X axis wrong by a factor of 2: It should go from DC
to Fs/2, not DC to Fs. It's not clear whether this affects your results by 3
dB or not, can't quite tell from the plots, since you didn't include a grid.
Let's ignore it.

You also managed to get 40 dB of processing gain out of a resolution BW
increase of 100. (With 1 frame, 4224 symbols, you show the peak of the FAS
at around -105 dB, but with 100 frames, it goes up to -65.) That FAS
differential is correct, but you forgot that the FFT of the data -- which
you didn't include in your program -- also increases 3 dB per doubling of
the resolution BW, because you didn't normalize your FFT. So that's a 20 dB
processing gain error.

When you take these into account, your "422224" figure should show the peaks
of the FAS at least 20 + 17 = 37 dB below where they are. In other words,
right where they started from, as shown in our presentation and in your
first slide. And the result is that the FAS peaks are about 23 dB below the
signal and thus boost the average signal level by around 0.02 dB.

Finally, as Jose has pointed out, when the THP is in the system, none of the
above matters at all.

If you want to argue some more, I guess I could modify your program to do
the analysis along the lines described above, and post the results to the
reflector.  But how about if we declare a draw on this particular sub-issue
and just drop it?  We've really tried our best to respond clearly and
technically to your concerns on this, because it's an important issue, but I
think we're getting to the point of diminishing returns, in terms of time
spent.  As Jose mentioned several times during the presentation, this
framing sequence is only a proposal anyway, and if there really are many
folks beside yourself who are genuinely concerned about the FAS EMI issue --
despite all the above -- then we can continue the technical debate, or just
change the framing to something else that people are happier with.  It's not
an important aspect of the overall 12-PAM proposal. But as far as we can
tell, it's simply not an EMI consideration as it is.


Glenn Golden
Principal Engineer
Teranetics, Inc.
ggolden@teranetics.com