The TA path may have improved a bit, so I will run a WOLF session again
tonight on 137.350 kHz, from 2200 to 0330Z with normal power. A QRP
session worked pretty well in the eastern US/Canada last night.
I responded to a message on the "Lowfer" reflector with some information
that may be of use to those playing with this stuff. Quoted below.
John, W1TAG/WD2XES
----------------------------------------------------------------------
KU4XR's pre-sunrise copy looks a lot better than the last night's. There
really isn't anything to criticize. But let me pass along what I know in
general.
First off, I have been providing a pretty much nailed-down signal, right
on frequency, and my transmitting computer's sampling rate correctly
specified. That results in a signal that doesn't drift in frequency, and
each frame of data lines up with earlier ones, allowing copy to build
up. So the stuff to watch for is on the receive end, in this case.
Second, please realize that WOLF represents a case of arrested
development. Stewart Nelson wrote the command-line version of the
program, did a couple of updates, and then moved on to other things. At
the point he left it, a lot of diagnostic elements were still in each
output line. One assumes that if development had continued, a lot of
that stuff would have been omitted, and nice graphical cues provided to
help diagnose sending or receiving problems. DL4YHF very graciously took
the original command-line program and wrapped a nice "GUI" around it,
allowing easier setup and operation. But the resulting text output has
remained the same.
f: is the decoded frequency offset in Hz. As long as you are within 1
Hz, it doesn't make much difference. But, once you start decoding a
signal, that reading should stay steady. An increasing or decreasing
reading would suggest receiver drift more than anything.
pm: is a relative power measurement, and once decoding starts, should
increase line to line, assuming that fading doesn't get in the way. But
if it jumps by more than 4000 per line, then overload has set in, and
nothing can be trusted. Very low readings suggest that you should
increase the input level from the receiver.
jm: These are internal framing values that are particular to each
receiving run. The numbers themselves don't mean anything. Once the f:
readings show lock-on, the jm: numbers should stay steady. Assuming that
the transmitting end sampling rate is correct, then changing jm: numbers
indicate a wrong sampling rate at the receiving end. If the rate you
have entered is too low, the jm: figures will drift positive. If the
rate is too high, the jm: will head negative. Drift in these readings
means that successive frames of data will not be aligned, and copy will
not build up as hoped.
q: These are signal to noise readings. The first number is s/n in the
"reference" channel (a known sequence of numbers transmitted in every
frame), and the second is s/n in the data channel. Ignore the second
one, and focus on the first. The signal to noise numbers should go more
positive as copy builds up. The threshold of decoding should be around
-3. Anything greater than that generally produces correct copy. Fading
will complicate the analysis, of course.
If you are correctly decoding a signal after, say 5 lines, there's no
sense in running very long decoding sessions. Better to limit them to
maybe 8 lines in that case, and allowing things to refresh. The decoder
is a big "flywheel," which means that you may receive a signal long
after it has gone off the air. There's another reason for not decoding
forever. There may be so much copy built-up that it takes a while to
degenerate back to noise.
Regarding sampling rate at the receiving end, tweaking it to bring the
f: closer to zero is only valid if your receiver is indeed putting out
the correct frequency. A better approach would be to throw it maybe 5 Hz
up, and watch what happens with the jm values. Then throw it 5 Hz below
the original value, and watch jm again. You might then be able to
interpolate between the two limits, and hit the correct rate pretty
closely. Of course, if you have a precisely known audio frequency source
on hand, use WOLF's calibration routine to determine the sampling rate
exactly.
Hope this is of some help.
John, W1TAG
|
