Stewart,
By the sounds of what you wrote, WOLF could become the mode of choice
for crossing the pond with a Part 15 signal level. I wish I knew how to
write code...
--
Mike
WE0H
WD2XGI
Stewart Nelson wrote:
Hi Wolf and all,
I just posted a copy of the WOLF sources at
http://www.scgroup.com/ham/wolf-source.zip
This has the complete environment; if you have MS VC++
you should be able to build it right away. Binaries
are also included, so you can see if the build gives
the same results.
The code is simple C, so it should not be hard to
build it with Borland or GCC. All the real work
is done in wolf.cpp; there are various utility
functions in fft.cpp.
Although I don't presently have time to write new code,
I'd be glad to answer any questions that may come up.
In addition to a GUI and real-time operation, here are
some features I'd like to (eventually) see:
1. Slow it down! Instead of a raw rate of 10 bps,
operation at e.g. 1 or 2 bps would greatly
reduce interference to stations operating on
nearby frequencies, and permit operation between
LORAN lines. A slower format would also be much
more tolerant of timing errors, in a future system
using synchronized clocks.
I believe that reducing the data rate is a simple
matter of adjusting some parameters, but there
are two problems: a) It's likely that many Tx or
Rx would not be phase-stable over the 8 or 16
minutes that a frame would now take. One would
need to add a "stability" setting to allow
searching for carrier frequency and phase over a
selectable fraction of a frame. b) It would be
a shame to have to wait 16 minutes for results,
even when the incoming signal is strong. One
could perform a decode with e.g. 1/4 of a frame,
substituting "erasures" for the missing bits.
2. Provide for Tx/Rx bit timing synchronization.
This could use GPS or another external source,
or simply depend on accurate computer clocks.
That should greatly improve sensitivity, by
eliminating false reference pattern sync on
weak signals.
3. Implement "smart" signal averaging, weighting
the incoming message symbols according to the
quality of the received reference symbols.
That would avoid degradation of data received
during good propagation, by noise received
during prior poor propagation. Also, when
the received reference is "excellent", the
decoder could reset, allowing different
messages to be sent in each frame.
A combination of (2) and (3) should permit
operation at "any" SNR, though it would of course
take 100 times longer to receive a signal 10 dB
weaker.
4. Implement some means of Tx/Rx carrier sync.
This probably requires GPS at the Tx end,
though it may be possible to use LORAN QRM
on receive. First, that would improve LF
skywave performance by a few dB. However,
on a long-term phase stable path, e.g. VLF
or groundwave, it should permit operation at
any SNR, taking only 10 times longer to
receive a signal 10 dB weaker.
If different folks are interested in tackling
these topics, perhaps I could act as a coordinator.
73,
Stewart KK7KA
|
