Return-Path: Received: (qmail 19081 invoked from network); 11 Feb 2002 12:45:53 -0000 Received: from unknown (HELO warrior.services.quay.plus.net) (212.159.14.227) by excalibur.plus.net with SMTP; 11 Feb 2002 12:45:53 -0000 X-Priority: 3 X-MSMail-Priority: Normal Received: (qmail 22745 invoked from network); 11 Feb 2002 12:45:50 -0000 Received: from unknown (HELO post.thorcom.com) (212.172.148.70) by warrior.services.quay.plus.net with SMTP; 11 Feb 2002 12:45:50 -0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Received: from majordom by post.thorcom.com with local (Exim 3.33 #2) id 16aFnE-0005MW-00 for rsgb_lf_group-outgoing@blacksheep.org; Mon, 11 Feb 2002 12:42:48 +0000 Received: from e21.nc.us.ibm.com ([32.97.136.227]) by post.thorcom.com with esmtp (Exim 3.33 #2) id 16aFnC-0005MR-00 for rsgb_lf_group@blacksheep.org; Mon, 11 Feb 2002 12:42:47 +0000 Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.ibm.com [9.37.3.208]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id GAA109412 for ; Mon, 11 Feb 2002 06:37:05 -0600 Received: from usa.net (ss4.bld.socks.ibm.com [9.14.4.69]) by southrelay01.raleigh.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1BCfqP187936 for ; Mon, 11 Feb 2002 07:41:52 -0500 Message-ID: <3C67BBEC.852B5AA4@usa.net> Date: Mon, 11 Feb 2002 13:41:16 +0100 From: "Alberto di Bene" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rsgb_lf_group@blacksheep.org Subject: LF: Re: Jason: 65 channels? References: <93.17cd74f6.2995bcec@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group Sender: MarkusVester@aol.com wrote: > G'day Alberto, Steve and all, > > its great to see the concept of FDK and its friendly implementation in > Jason. But, one question came to my mind: Instead of using a 4-bit pair for > each 6 bit character, why not take it all the way and transmit 6 bits at > once? Of course, this would mean 65 frequencies instead of 17, four times the > bandwidth at first glance. > > But then you could double the symbol duration and halve the FFT bin bandwidth > to 42 mHz, picking up some SNR on the way. Additionally, even with a Hamming > or Bartlett window, the noise in channels only two bins apart should have no > significant correlation. Thus the total occupied bandwidth would increase > from the current 4.12 Hz to no more than 5.42 Hz. > > What do you think? Hello Markus, I have been out of town for the weekend, so am able to answer only today. If I do correctly understand you, what you propose is to multiply by 4 the number of the signalling elements, halving at the same time their spacing and the baud rate, for an unchanged throughput in terms of bit/sec. This would led to a doubling of the bandwidth. Then you implicitly suggest a reduction of the number of bins between different elements from 3 to 2, thus gaining another 0.666... factor of reduction of the band, which would go from 4.12 to 4.12 * 2 * 0.6666... = 5.48 (roughly) Hz. Please correct me if I misunderstood you. I have one remark on this. Placing the signalling elements on alternate bins (spacing of two instead of three as in the present scheme), can cause uncertainty due both to the leakage intrinsic in the FFT process, and to possible instabilities of the Tx and/or the Rx. In other words, let's make a simple example. Let's number the bins 1, 2, 3, 4, 5, 6 etc. Now, suppose I use the even numbered bins only. In the case I find a signal in bin number 5, should I consider it belonging actually to the signalling element of bin 4 or of bin 6 ?? There is no way to tell. Using three bins as spacing, as I do now, and keeping the previous example, the 'correct' bins are, suppose, the Nr. 1, 4, 7, 10, etc. If I find a signal in bin 5, I attribute it to bin 4, as I do for bin 3. So, bin 6, 7, 8 are all 'belonging' to bin 7, and so on. In this way I have more chances to keep the signalling elements orthogonal, as is required for a correct MFSK uncoherent decoding. So, to sum up, I would tend to discard the proposal of reducing the bin spacing. What remains is the proposal of doubling the bandwidth in exchange for the possibility of keeping unchanged the throughput while at the same time increasing the S/N ratio. It can be done, but I would like to know also what the general consensus is on this, and any possible comments from the other LFers. TNX. 73 Alberto I2PHD