[Lowfer] WOLF Copy from last night

[John Andrews]

Thanks to Ralph, Fred, Tom, Mike Staines, Dick, Lloyd, Dave Crawford, 
and Hartmut for reports from last night. Hope I didn't leave anybody out.

Long message: Please ignore if you're not interested in these weak 
signal digital modes!

First, a little background on WOLF for those who have not encountered it 
before. Stewart Nelson developed the coding scheme and wrote a 
command-line program to transmit and receive it. The idea was to take 
advantage of the stable frequency/phase in LF transmission, applying a 
lot of error coding and summing up the copy over a period of time. 
Stewart decided to use a 15-character message with the upper-case 
alphabet, numbers 0-9 and a few punctuation symbols being available. 15 
characters are always sent, with spaces added by the program if needed. 
Each character is assigned a number from 0-39. Those numbers are then 
turned into five 16-bit numbers for a total of 80 bits. Forward error 
coding is then applied at a 1 to 6 rate, which increases the number of 
bits to 480. Then a 480 bit array of 0's and 1's is interleaved, so that 
every other bit is from that array, and the message is up to 960 bits. 
Since the 480 bit array is also coded into the receiving program, it 
becomes a "reference channel" to allow tracking of signal strength and 
timing errors.

The 960 bits are then spit out over and over, until the operator changes 
the message and restarts the transmitting end. Each 960 bits represents 
one line of copy on your screen. Since I was sending at 20 bits per 
second last night, each line (after the three intitial ones) represents 
48 seconds, and the time values on the left should reflect that. The 
transmitted signal is straight BPSK with some shaping. A linear PA is 
needed to keep the bandwidth down, just as with PSK31. Last night's 20 
bit/second signal was less than 100 Hz wide.

You can't copy this stuff by ear! Originally, the command-line version 
of the program required you to record the signal into a .wav file, and 
then process it. A few years ago, Wolf Buscher, DL4YHF, took the 
original code and built the WOLF GUI program which we now use. In the 
process, he made the program capable of decoding in real time, though 
you can still do the record/playback thing if you wish. The original 
WOLF program ran only at 10 bits/second, and DL4YHF added several other 
speeds.

A WOLF QSO can easily be done by working in time blocks that are known 
at each end. Station A might transmit starting at the top of the hour 
for 10 minutes. Station B takes over at :10 past the hour, and so forth. 
To date, I have been involved with WOLF QSO's with Jay, Dex and 
Laurence, so it does work for more than beaconing. WOLF's weak signal 
capability is about the same as QRSS60, so it is very valuable for 
signals totally buried in the noise at aural receiving bandwidths. It's 
overkill for many of you who copied it last night, but makes good 
practice if weaker signals come along.

If you look at the output from the decoder, the first three lines are 
different, and can be ignored for the present discussion. If you get 
correctly decoded copy in those lines, you've got a pretty strong 
signal. Staring with line 96, here's what the numbers mean:

t: is the timing of each line as described above, in 48 second increments.

f: is the measured frequency deviation in Hz from the value you entered 
in the setup. 10 Hz is the maximum deviation permitted, and you can set 
narrower windows. If that value changes and the copy still remains 
clear, then something is drifting at the sending or receiving end. Note: 
my transmitter setup should be pretty solid for frequency, being based 
on a GPS-disciplined OCXO.

pm: is a numerical representation of the buildup of copy. If it 
increases in steps of 4000 or more, then the detector is being 
overloaded, and you should reduce RF or AF gain. A steady increase means 
that each line of copy is adding to the previous ones. Note that if I 
change the message, the pm: values will fall apart, and have to rebuild.

jm: is frame timing for each line. The actual number is not important, 
but if the numbers jump around and copy is still correct, then you 
should try to determine your sound card's actual sampling rate and enter 
it into the WOLF setup. If the sampling rate is way off, this will 
prevent the copy from building up correctly, and will degrade the weak 
signal performance. With strong signals, you can get away with a lot.

q: These are two numbers representing signal to noise ratio, and are a 
good way to track signal strength and fading. The first is for the 480 
bit reference channel, and the second for the remaining 480 bit data 
channel containing the message. I usually watch the first column. Weak 
signals will begin to decode around -5, and are usually solid by -3. 
Last night's reports were mostly positive numbers, indicating a strong 
signal. Fading will be apparent, and any change in message will swing 
the q: values in the negative direction.

I'll make some comments on the individual reports later today. Again, 
thanks!

John Andrews, W1TAG / WE2XGR/3