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