Return-Path: Received: from rly-de07.mx.aol.com (rly-de07.mail.aol.com [172.19.170.143]) by air-de07.mail.aol.com (v126.13) with ESMTP id MAILINDE071-4eb4b228c55391; Fri, 11 Dec 2009 13:16:19 -0500 Received: from post.thorcom.com (post.thorcom.com [193.82.116.20]) by rly-de07.mx.aol.com (v125.7) with ESMTP id MAILRELAYINDE074-4eb4b228c55391; Fri, 11 Dec 2009 13:15:50 -0500 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1NJA0h-0000oS-QN for rs_out_1@blacksheep.org; Fri, 11 Dec 2009 18:14:35 +0000 Received: from [193.82.116.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1NJA0h-0000oJ-AZ for rsgb_lf_group@blacksheep.org; Fri, 11 Dec 2009 18:14:35 +0000 Received: from out1.ip08ir2.opaltelecom.net ([62.24.128.244]) by relay1.thorcom.net with esmtp (Exim 4.63) (envelope-from ) id 1NJA0g-0002RK-JS for rsgb_lf_group@blacksheep.org; Fri, 11 Dec 2009 18:14:35 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQEAMEaIktOlpWR/2dsb2JhbACIaM1BhCsEgWM X-IronPort-AV: E=Sophos;i="4.47,383,1257120000"; d="scan'208";a="317126389" Received: from unknown (HELO your91hoehfy9g) ([78.150.149.145]) by out1.ip08ir2.opaltelecom.net with SMTP; 11 Dec 2009 18:14:26 +0000 Message-ID: <006801ca7a8d$c8842000$0301a8c0@your91hoehfy9g> From: "mal hamilton" To: References: <38A51B74B884D74083D7950AD0DD85E828AC12@File-Server-HST.hst.e-technik.tu-darmstadt.de> <4B22410F.1000306@telia.com> Date: Fri, 11 Dec 2009 18:14:30 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Karma: unknown: X-Spam-Score: 0.0 (/) X-Spam-Report: autolearn=disabled,none Subject: Re: LF: "Gain" between qrss3 and qrss10? Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-SA-Exim-Scanned: Yes Sender: owner-rsgb_lf_group@blacksheep.org Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group X-SA-Exim-Rcpt-To: rs_out_1@blacksheep.org X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-AOL-IP: 193.82.116.20 This is what I have been saying all along and ofcourse there are Wireless Operators who know their subject and Appliance Operators fumbling with data. If you have enough bandwidth like microwave freqs then ARQ helps but on LF/MF and even HF under poor propagation condx or QRM it goes on for ever trying to get a correct response. to proceed with the traffic. I have used and experienced these various systems performing commercially over the years. If you have lots of tfc to shift then one has to perservere otherwise use CW and a professional operator. Imagine trying to pass a position report on an aircraft on HF using ARQ in poor or qrm condx, the aircraft could have landed by the time the msg was received. The fastest and most reliable modes on MF/HF for this type of operation was CW or SSB and is still used. For efficiency and simplicity and cost 500 kcs is still a good bet for the marine service and that is why they are reluctant to let it go. A professional CW operator will win out in the end, he only needs a few basic components and a piece of wet string to transmit his message via wirelss. G3KEV ----- Original Message ----- From: "Andy Talbot" To: Sent: Friday, December 11, 2009 1:26 PM Subject: Re: LF: "Gain" between qrss3 and qrss10? On this matter... For the recent talk I gave on weak signals at a Microwave Roundtable ( http://www.g4jnt.com/MartleSham.htm ) I made some simulated CW in Noise using accurately calibrated S/N levels. An interesting finding came to light, if you normalise the signal rate to the S/N, so making bandwidth irrelevent, most of the 'fuzzy' modes end up with a similar capability. In other words, Aural CW, QRSS, SMT Hell all need a similar S/N at their respective bandwidths to work. The actual normalised S/N for readability is subject to the operator's experience togther with Temperature/Time of day/mood/Age/Gender/Alcohol intake/Hunger/Weather or any other similar parameter, but there's no massive differences between any of them. So its all down to bandwidth. Even machine modes without error correction manage a not-too-dissimilar performance once their data rates have been normalised. However, if you spread the signal, intentionally, by adding FEC, the improvements can be enormous. As I think we all know only too well when comparing QRSS etc with WSPR, Wolf and other modes with heavy FEC. At least on microwaves we have the luxury of virtually unlimited bandwidth, so can operate in a true Shannon power limited channel to make the most of band spreading. Incidently, the usually quoted signal efficiency used on one axis of the Shannon curve "Bits/second/Hz" sounds uninspiring. But if, instead of Hz, you use the old term 'cycles per second', it becomes Bits/cycle. Which puts a whole new meaning and explanation to the axis on the Shannon curve, and elicited an "Oh Wow, yes, that IS an interesting way of putting it" when told to an experienced comms engineer. The term was actually used in Shannon's original paper of 1948, but seems to have got lost Andy www.g4jnt.com This email has been scanned for damaging side-effects by the health and safety police 2009/12/11 Johan H. Bodin : > Hi Stefan, > >> Or isn't it possible to give such a relation? > > Yes, it is not only possible, it is in fact quite simple: > When the speed is reduced by a factor K, the information bandwidth is > also reduced by the same factor. This allows you to use a receiver > bandwidth which is K times narrower without missing any information. The > nice thing is that the noise power passing through this bandwidth is > also K times smaller - The S/N ratio has improved K times (or 10*log(K) > dB if you prefer). In other words, you can reduce the TX power by the > same factor K and still enjoy the same SNR (if RX BW is is also made K > timer narrower). > > In visually received QRSS, the receiver bandwidth is equal to the RBW, > the "resolution bandwidth", which is approximately equal to the FFT bin > width (one pixel on Argo). > > QRSS30 is 10dB more efficient than QRSS3, in theory at least. > > 73 > Johan SM6LKM > > ---- > > Stefan Schäfer wrote: >> Dear LF, >> Does anybody know about the "gain" between QRSS3 and QRSS10 or QRSS30? I mean, if the noise in both cases is equal, how much can I reduce my tx pwr when switching from qrss3 to qrss10? Or isn't it possible to give such a relation? >> And: Was there ever a TA QSO in QRSS3? >> I am new on the reflector, sri ;-) >> >> Stefan / DK7FC >> >> > >