Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

LF: <Tech> Re: more Wolf tests

To: [email protected]
Subject: LF: <Tech> Re: more Wolf tests
From: "James Moritz" <[email protected]>
Date: Tue, 1 May 2001 15:33:26 +0000
Organization: University of Hertfordshire
Reply-to: [email protected]
Sender: <[email protected]>
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


<Prev in Thread] Current Thread [Next in Thread>