Re: [10GBT] Request for Cat6 Emissions Characteristics
There are several problems with this code.
1. First of all you forgot to include the data stream, which accounts
for 99.8% of the PAM12 frame energy. The spectrum you are showing
corresponds to the remaining 0.2% as Glenn described to you.
2. You made the same mistake as in your rao_1_0704.pdf presentation
(most slides from 29 to 52). You forgot to include the THP again, which
was approved unanimously by the task force. The THP will effectively
whiten the data, so the 0.02dB peaks will likely not be there
3. You increased the duty cycle from 8/5000 to 8/128.
If you need further help I can fix these problems for you,
From: stds-802-3-10gbt@IEEE.ORG [mailto:stds-802-3-10gbt@IEEE.ORG] On
Behalf Of sailesh rao
Sent: Sunday, July 25, 2004 5:39 PM
Subject: Re: [10GBT] Request for Cat6 Emissions Characteristics
OK, I agree with you to keep these e-mails technical in order to advance
I've written a short matlab code (glenn.m) to illustrate the PAM12 PSD
problem. I'm using 128 symbols as the repetition rate for the frame
start symbols in order to keep the vector sizes sane in matlab.
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
I hope this clears up the confusion. I think the problem will manifest
itself in the CISPR average PSD requirements, though I'm not sure of the
minimum time constant for the averaging. I believe that the FCC only
uses quasi-peak averaging in our frequency range of interest, but I'm
not sure what the time constants are there either.
I welcome any inputs from the EMI experts.
>From: Glenn Golden <firstname.lastname@example.org>
>Subject: Re: [10GBT] Request for Cat6 Emissions Characteristics
>Date: Sun, 25 Jul 2004 17:33:58 -0600
>Sailesh Rao writes:
> > You are adding these peaky bumps in the PSD to the data "average".
>Of course they're adding. But to assess their effect, it's necessary
>to account for the duty cycle at which they are being added, which you
>are not doing.
> > This gets worse. A closer reading of tellado_1_0704.pdf reveals that
> > fixed patterns are being sent once every microsecond on all 4 wire
> > pairs simultaneously!
>An even closer reading would reveal that the period is 5 usec, not 1,
>and an even closer reading than that would reveal that the peak PSD at
>this rep rate is 23 dB below the data signal level, and consequently
>The proposed frame alignment signal (FAS) consists of 112 bits out of
>every 52833. This is represented on each pair with a sequence of 8
>symbols -- different on each pair, and intentionally synchronized
>across all 4 pairs -- out a total frame length of 4224 symbols. Thus,
>the repetition period is 1/825 MHz * 4224 = 5.12 usec, the rep rate is
>1/5.12 usec = 195 kHz, and the duty cycle 8/4224, about 0.19%. The
>power of the FAS is thus
> 10*log10(8/4224) = -27.2 dB
>below the steady state power. The frequency peak of the FAS power
>spectrum is roughly 4 dB above the average FAS power, hence around
>23 dB below the data signal. As has Jose and Seki have pointed out,
>this represents an increment of 0.02 dB above the average power level.
> > Talk about peaky PSD bumps in the PAM12 transmit spectra, yikes!
>Talk and "yikes!" all you want; it does not affect the arithmetic.
>At 23 dB below the average signal power, your local FCC/CISPR
>certification shop would be hard pressed to even detect the presence of
>these "peaky PSD bumps", much less measure them. If you believe
>otherwise, then sharpen your pencil and make the case.
> > I disagree that the "ripple is small". If we keep sending the same
> > pattern over and over, once every MHz, the ripple won't be small.
>I'm not sure I appreciate the units of measurement you're using, but in
>any case, the ripple in the FAS will always be the same size regardless
>of the rep rate: It will be +/- 4 dB relative to the FAS average value.
>The rep rate determines the average value: 27 dB below the data signal.
> > It is technically incorrect to pretend otherwise.
> > Heck, I have a good mind to add a large number of dBs to the
>"Yikes!" and "heck" are not technical arguments. Perhaps you would like
>to offer one?
Express yourself instantly with MSN Messenger! Download today - it's