From owner-stds-802-3-hssg@ieee.org Tue Feb 29 15:43 GMT 2000 Received: from gatekeeper.pdd.3com.com (gatekeeper [161.71.169.3]) by isolan.pdd.3com.com (8.9.1b+Sun/8.9.3) with ESMTP id PAA18828; Tue, 29 Feb 2000 15:43:29 GMT Received: from ruebert.ieee.org ([199.172.136.3]) by gatekeeper.pdd.3com.com (Netscape Messaging Server 3.6) with ESMTP id AAA10B3; Tue, 29 Feb 2000 15:41:44 +0000 Received: by ruebert.ieee.org (8.9.3/8.9.3) id KAA16776; Tue, 29 Feb 2000 10:01:05 -0500 (EST) Message-Id: <4.2.0.58.20000229064314.00a867e0@mail.bayarea.net> X-Sender: jmw@mail.bayarea.net (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 29 Feb 2000 07:00:29 -0800 To: NetWorthTK@aol.com, vivek@cicada-semi.com, stds-802-3-hssg@ieee.org From: jmw Subject: Re: PAM-5, what are your BERs ? In-Reply-To: Mime-Version: 1.0 Sender: owner-stds-802-3-hssg@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: stds-802-3-hssg X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-hssg-approval@majordomo.ieee.org X-Lines: 60 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 2592 Edward, my $0.02: it is not always the case that because a thing seems to be true on first examination, it must therefore always be true. SNR is certainly a critical issue for any receiver in any communication system. Claude Shannon proved that a long time ago. but aside from bandwidth and data rate issues (for the moment, of course), if "signal" and "noise" are sufficiently statistically independent, then the two can be separated and the signal recovered. for this case it is not enough to look at a 'scope display, say to yourself "gee, that looks like nothing but noise to me", and decide you're done. -- J M Wincn Cielo Communications, Inc. 325 Interlocken Pkwy, Bldg A Broomfield, CO 80021-3497 mwincn@cieloinc.com Voice: 303-464-2264 Cell: 408-394-5283 At 01:15 AM 29-02-2000 -0500, NetWorthTK@aol.com wrote: >Hi Vivel: > > >From theoretical point of view, you reasoning makes some points. However, >from the real implementation point of view, it is not quite true. Before >starting analyzing the frequency response, just ask a question: "If we can >simply keep equalizing the receiving signals to bring them back to the >looking-alike to the original, transmitting signal, why we bother all those >bandwidth issues? There must be some limitations to the equalization >technique. > >The eye closure is caused by the insufficient bandwidth of a receiving path; >as a result, the narrow pulse (higher frequency pulse) is much more >attenuated than the wider pulse (lower frequency pulse). We can cascade a >high-pass frequency response equalizer to suppers the amplitude of a wide >pulse, and keep the amplitude of the narrow pulse remain unchanged (but not >amplified) to open the eye. However, if the amplitude of a narrow pulse is >already too small to meet the minimum S/N requirement, the equalizer is >useless. Theoretically, a linear amplifier can be added to bring the signal >amplitude up to meet the minimum S/N requirement. The linear amplifier will >need a BW larger than the transmitting signal rise time. Furthermore, any >deficiencies in the linearity, will add both timing and amplitude distortion >to the received data. The additional distortion is not included in the >jitter specification; as a result, the link will cause higher BER. >Especially in a high data rate link, a linear amplifier may cause more errors >than the expected benefit. In practice, it is impractical to add a linear >amplifier. > >The right way is to keep eye open at the receiver input. > >Regards, > >Ed Chang > >NetWorth Technologies, Inc.