Message-ID: <9155.200105011433@gemini>
From: "James Moritz" <j.r.moritz@herts.ac.uk>
Organization: University of Hertfordshire
To: rsgb_lf_group@blacksheep.org
Date: Tue, 1 May 2001 15:33:26 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 8bit
Subject: LF: <Tech> Re:  more Wolf tests
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Sender: <majordom@post.thorcom.com>

Dear Stewart, Andy, LF group,

I will sort out some recorded .wav files - this will probably take a 
few days, as I have to find a way of transferring the requisite 
megabytes from my PC at home to the one at work to be e-mailed; 
I have a Zip disk drive somewhere that should do it.

I will run the Wolf beacon again this evening for those who are 
setting up their receiving systems. I will use a frequency of 
137.4400kHz again, and transmit at the 300mW ERP level from 
2000 to 2100 utc, then from 2100 onwards at a 30mW ERP level. I 
will send a CW ID and carrier at the signal frequency for a few 
minutes at the start of each hour and half-hour period, for 
frequency checking purposes. If you are trying to receive the 
signal locally, remember that Wolf will not decode strong signals, 
so back the gain off so that the signal level is at least 20 or 30dB 
below the clipping level as indicated by the recording software.

Regarding Andy's comments, I have been thinking along similar 
lines for somewhat different reasons. I don't claim to have 
expertise in this field, but suppose the data rate of Wolf was 
reduced by a factor of 10, ie, to 1 bit per second. What would be 
the effects?

-The signal bandwidth would be reduced to a few Hz, greatly 
reducing pressure on the available spectrum

-The reduced transmitted data rate should be largely made up for 
by the increased SNR possible in the narrower bandwidth, reducing 
the number of data frames required to be processed for successful 
decoding. So the overall throughput should be little changed.

- The signal bandwidth would fit in the gaps between the Loran 
lines, etc., like a QRSS signal, so presumably further improving the 
SNR.

-The overall amount of data to be processed in a given time would 
be reduced by an order of magnitude - this would reduce the time 
taken for the PC to process the received data, and so bring 
decoding nearer to "real time" without requiring a very fast PC.

-Because each bit period is ten times longer, but the overall 
decoding period would be roughly the same, the bit-timing accuracy 
required from the soundcard or other interface would be reduced.

The main drawback would be that increased demands would be 
made on TX and RX stability - probably an overall tolerance of 
about +/-0.1Hz or 1ppm. While this is easily acheived by equipment 
with temperature stabilised or compensated references, it is a bit 
much for most amateur HF gear. Perhaps it would be possible to 
improve the frequency tracking capabilities of Wolf to cope with 
this.

I am not sure if I am just being naive, but it seems to be worth 
looking at the idea.

It would be easy to try experiments along these lines, for example I 
could generate a slowed-down Wolf signal by a trivial alteration to 
the clock rate of my EPROM-based keyer. Receiving would be a 
little more difficult, but I imagine that VE2IQ's "Crunch" ought to be 
able to speed up the 1 bit/sec to 10 bits/sec, by setting a 10:1 
"compression ratio". I guess it wouldn't be very hard to alter the 
Wolf program to achieve the same ends.

I have done some experiments on the performance of Wolf signals 
in white noise from a noise generator - measuring signal and noise 
levels using a true-RMS voltmeter in 300Hz BW, I find that Wolf will 
successfully decode within 1632 seconds with a SNR of -34dB. As 
Andy suggests, there seems to be quite a sharp threshold. I plan to 
try some more experiments with CW and Loran interference to see 
how it compares.

Cheers, Jim Moritz
73 de M0BMU