Re: [10GBT] Discussions on ...
Sailesh,
128-point checkerboard constellation = 128-point Double Square constellation
(128-DSQ). The designation "Double Square" alludes to an algorithmic symbol
construction and labeling method for this type of constellations.
When I concentrated on the question of the optimum modulation rate for
10GBASE-T, which I found in the 800 Mbaud range (ungerboeck_1_0504.pdf, Long
Beach; see also takatori_1_0504.pdf), I said nothing about specific
modulation & coding to accomplish the "achievable bit rates" vs modulation
rate.
This time I am speaking about a particular modulation & coding scheme
(namely 128-DSQ + LDPC), which I find best suited for transmission at the
around 800 Mbaud rate. I would appreciate if the notions of "12PAM" or
"8PAM" camp would disappear from our 10GBASE-T discussions. Instead let's
concentrate on the various not necessarily connected technical issues and
the proposals made on this issues.
The specific issues at hand are: (a) in what range should the 10GBASE-T
modulation rate be; then (b) what modulation & coding should be used to
accomplish transmission at a modulation rate within this range.
Regards, Gottfried
-----Original Message-----
From: stds-802-3-10gbt@IEEE.ORG [mailto:stds-802-3-10gbt@IEEE.ORG] On Behalf
Of sailesh rao
Sent: Mittwoch, 15. September 2004 20:07
To: STDS-802-3-10GBT@listserv.ieee.org
Subject: Re: [10GBT] Discussions on precoder decisions
Gottfried,
Is the "Double Square" constellation the same as the "Checkerboard"
constellation you were telling me about last week? If not, this would be the
5th constellation I've heard about from the PAM12 camp.
Here's the list so far:
1. Original PAM-12 "donut" constellation.
2. PAM-12 Compapiano-Glazer "cross" constellation.
3. PAM-12 multi-dimensional "Kabob" constellation.
4. Checkerboard constellation.
5. PAM8/16 Double Square constellation.
A general observation is that instead of researching PAM12 constellations,
the task force would be well served if we can converge around the PAM-8
proposal and conduct a working session on the standards draft at the interim
meeting.
Regards,
Sailesh.
srao@phyten.com
>From: Gottfried Ungerboeck <g.ungerboeck@BLUEWIN.CH>
>Reply-To: "IEEE P802.3an" <STDS-802-3-10GBT@LISTSERV.IEEE.ORG>
>To: STDS-802-3-10GBT@LISTSERV.IEEE.ORG
>Subject: Re: [10GBT] Discussions on precoder decisions
>Date: Wed, 15 Sep 2004 10:56:34 +0200
>
>George,
>
>the 128DSQ constellation ("double square") is the natural go-in-between
>8 PAM and 16 PAM, much more so than 12PAM. Contrary to 12PAM, all
>encoding, decoding, and precoding operations are based on powers-of-two
arithmetic.
>128DSQ has been known for a long time in the literature and its good
>fit with precoding has been well described.
>
>On precoding, please see ungerboeck_1_0704.pdf (Portland). One fixed
>IIR-type precoder is enough. If the group cannot agree on a single
>fixed precoder, then let it be a very small set (2?) of fixed
>precoders, one being selected preferrably during auto negotiation.
>
>Regards, Gottfried
>
> _____
>
>From: stds-802-3-10gbt@IEEE.ORG [mailto:stds-802-3-10gbt@IEEE.ORG] On
>Behalf Of George Eisler
>Sent: Mittwoch, 15. September 2004 06:03
>To: STDS-802-3-10GBT@listserv.ieee.org
>Subject: Re: [10GBT] Discussions on precoder decisions
>
>
>Hugh,
>
>Thanks again for taking the badly needed lead on urging along the
>decision making. The precoder definition is clearly in need of
>consideration, although I think it will take simulation work to really
>nail it down. Of course you can't finish it if you don't get started.
>
>On last week's call, I was surprised by the "double square"
>contribution, with it's sort of 16/8 PAM flavor. It seems to open the
>case up rather than converging, but I wonder what's your take on it? I
>was going to call you, only to realize that I don't have your phone
contact.
>
>George Eisler
>310 459-9225
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/