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
|
