To: rsgb_lf_group@blacksheep.org
From: John Andrews <w1tag@charter.net>
Message-ID: <569011C3.8050309@charter.net>
Date: Fri, 8 Jan 2016 14:45:07 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.0
MIME-Version: 1.0
Subject: LF: WD2XES WOLF again
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Status: O

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