re Jim'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?
I was not proposing just slowing Wolf down, I was arguing the merits of
using Uncoded BPSK for the same performance (a-la VE2IQ & Coherent) but
at 1 b/s - this would give a few extra dB capability immediately. With
Wolf coding as well, this could give 10 dB extra but at 16 minutes for a
15 character message.
-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.
Although I think you said that here
-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 bit timing accuracy needs to be of the order of the bit interval, so
at 1b/s 10 times better timing accuracy will be needed, but at this
speed it becomes easier to set to UTC ticks - from MSF or GPS etc.
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.
As for frequency stability, 1ppm really ought not to be a problem now -
as I've said many times before here. The microwavers have regularly
been getting that sort of stability for years when out /P, without even
resorting to TCXOs - merely using an overtone crystal in a series
resonant Butler oscillator in the region of 100MHz with a clip on
crystal heater costing a couple of pounds. (Digital dividers operating
at 100MHz to generate LF freqs are straightforward now, 100MHz is no
problem for CMOS logic these days).
Alternatively small TCXOs are very widely available now, every mobile
phone has one, and they are available from all the component suppliers
for a few pounds. These lower cost TCXOs are specified at 2ppm, which
nearly always means at least 1ppm in practice or else they couldn't
guarantee the figure, and many can be trimmed to within 0.2ppm and can
stay there for months, even if turned on and off repeatedly. A 5MHz
TCXO driving a DDS gives you just about the most versatile LF signal
source imaginable 0 to 2 MHz in steps of 0.0012Hz. The clock doesn't
even have to be a round value of frequency - anything can be pressed
into service for driving a DDS chip.
After a concerted effort and much frustration with numbers that turned
out to be coded using Octal notation, last weekend finally manage to
'crack' the Wolf coding sufficient to be able to generate code from my
own software written in another language which agrees with that from
software supplied by Stewart. The next stage is to port to a PIC
processor to allow a small beacon generator to be constructed with data
that can be changed on the fly.
Andy G4JNT
--
The Information contained in this E-Mail and any subsequent correspondence
is private and is intended solely for the intended recipient(s).
For those other than the recipient any disclosure, copying, distribution,
or any action taken or omitted to be taken in reliance on such information is
prohibited and may be unlawful.
|
