Content-Transfer-Encoding: 8bit
Message-ID: <200103061842.NAA3114846@indyweb.cgocable.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Date: Tue, 06 Mar 2001 13:42:53 -0500
To: rsgb_lf_group@blacksheep.org
From: "Bill de Carle" <bill1@cgocable.ca>
Subject: Re: LF: <TECH>Transatlantic modes - what next?
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Sender: <majordom@post.thorcom.com>

At 05:50 PM 3/6/01 +0000, Jim Moritz wrote:
[..]
>What is required for a practical 2 way LF DX mode, capable of 
>operating at the extremes of distance and SNR? A while ago, 
>G4JNT posted an estimate of what might be theoretically possible 
>using different techniques; another way is to look at what is 
>needed to serve our purposes. I would suggest the following "wish 
>list":
>
>1)Be able to complete a minimal QSO (about 50 characters) in one 
>hour. This would give the lowest rate of signalling capable of using 
>the propagation lifts to complete a QSO "in one sitting".
>
>2)Be able to transmit/receive all alphanumeric characters and 
>essential punctuation/procedure signs, in order to be generally 
>usable by any station without special arrangements.
>
>3)Occupy a bandwidth of less than 10Hz - this is neccesary 
>because of the very limited spectrum available, and the fact that 
>several stations will be operating simultaneously. 
>
>The QRSS modes easily meet 2 and 3; in order to meet 1, a dot 
>length of about 7 seconds maximum would be required. With the 
>best possible conditions, I guess several stations might manage 
>transatlantic QSOs with these dot lengths. However, it would 
>probably not be enough to reach the more inland parts of Canada, 
>or the USA and further afield. By the way, I reckon about 6dB SNR 
>is needed to see a QRSS signal on a spectrogram under 
>favourable conditions; if there is much QRN, 10dB is probably 
>required. It is possible to see a trace of signal with 0dB or less 
>SNR. All this is fairly subjective, however.
[..]
>Then there are the "digital" modes, specifically BPSK. Currently, 
>most effort has been expended on the MS100, 10 bits per second 
>variety of BPSK. This easily meets conditions 1 and 2. However, 
>for the same signal levels, QRSS seems to do better with 
>acceptable, if much slower, speed. Also, the bandwidth occupied is 
>roughly 40Hz, too wide for condition 3. But with the 16 bits per 
>character coding scheme normally used for BPSK, 2250 
>characters per hour can be transmitted, far higher than is actually 
>required. So the bit rate could be greatly reduced, and/or the 
>coding altered to a greatly increased number of bits per character, 
>hopefully improving the readability of the signal. Reducing the 
>overall speed by a factor as much as 45 would still meet condition 
>1. To fit into a 10Hz bandwidth, the bit rate would have to be 2.5 
>bits/sec (MS400) or less, so you could encode each character with 
>up to 180 bits if you wanted to. Or, sticking with 16 bit codes, 0.22 
>bits/second (MS4500) would still be OK. What we want is the best 
>trade off between bit rate and encoding for very poor signal to 
>noise ratio. I don't know a great deal about this subject, but I 
>expect some readers of this reflector already know the answer. 

Apart from the bandwidth, I believe Stewart Nelson's WOLF system
is the best approach that most closely meets all the requirements.
It shouldn't be difficult to slow down WOLF's 100 msec keying rate
if you really have to reduce the bandwidth.  Of course Tx, Rx frequency
stability and accuracy will become increasingly important as with
any slow BPSK mode.

>So any suggestions/comments would be welcome -     well, almost 
>any! By the way, I now have BPSK at up to 1200W PEP from my 
>Decca TX, if anyone would like a sked/tests, etc.

If you'd care to run a test using WOLF, I'd be happy to send you the
results.

For more information on WOLF, see:

www.scgroup.com/ham/wolf.html

Bill VE2IQ