Re: [10GBT] More on the PAM12 emissions
Glenn,
Same response as to Jose.
Regards,
Sailesh Rao.
srao@phyten.com
>From: Glenn Golden <gdg@zplane.com>
>Reply-To: gdg@zplane.com
>To: STDS-802-3-10GBT@listserv.ieee.org
>Subject: Re: [10GBT] More on the PAM12 emissions
>Date: Mon, 26 Jul 2004 16:26:10 -0600
>
>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
_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/