WOLF was written by Stewart Nelson (KK7KA). WOLF means "Weak-signal
Operation on Low Frequency". WOLF can operate over a
wide range of signal levels. For example, a WOLF beacon transmits a 15-character
message repeatedly. If the received signal would be adequate for conventional
CW, copy will be displayed in 24 seconds (for the standard WOLF speed).
More background information can be found on Stewart Nelson's website.
GUI means "graphic user interface" in this case. The original WOLF implementation by KK7KA was a simple WIN32 console application. I (DL4YHF) tried to write a user interface for it in April 2005, using Borland C++Builder V4. At the moment, this is still "under construction", so please don't expect too much. The plan was...
The following items exist in the main menu (there may be more than explained
The main tab contains the tuning scope, the "TX" / "RX" indicator (which is also a TX/RX control), an edit field for the transmitted text in the upper part, and the decoder output in the lower part. You can change the screen areas with a "screen splitter" control (the horizontal separator between tuning scope and decoder text list).
Buttons on top of the Decoder Output window:
The status line at the bottom of the WOLF window shows the current action of the program (or an error message), and the current buffer usage. Observing the buffer usage is important if your PC is fast enough to decode WOLF in real-time (if it's a 300 MHz Pentium 2, or better, it will be, and you can skip the next paragraph).
To understand what the "Buffer Usage" indicator (in the status line of the main window) shows, first an explanation how WOLF runs in real-time mode:
The WOLF GUI is a multi-threaded application. When using the soundcard, three different threads are running at the same time:
The "large buffer" can contain up to 96 seconds of audio data, because it is also used as a playback-loop for transmission. While receiving, it buffers the audio samples because the WOLF processing thread may "think" for a while, when it decodes the previously received frame. The "thinking"-time depends on the speed of your CPU. If the CPU is fast enough, WOLF decodes much faster than the samples are written into the buffer, and the buffer usage indicator rarely rises above 50 percent.
If the buffer usage exceeds 80 percent (while WOLF is "thinking"), try to reduce the CPU load from other threads and programs. This means:
Reduce the frequency resolution of the tuning scope. High resolution adds
a significant CPU load, because it uses a 32768-point FFT for the spectrum
display or the waterfall. Medium resolution (=16384-point FFT) consumes less
than half the CPU load, which gives the WOLF decoder thread more
On a 266 MHz Pentium 2, the buffer usage rose to a maximum of 75 %, with the waterfall running at medium resolution, and the frequency tolerance set to 1 Hertz.
If that is still not sufficient, turn the tuning scope off. On the 266 MHz P2, the maximum buffer usage dropped to 35 % when the tuning scope was off.
If even this doesn't help, reduce the frequency tolerance value on the WOLF Config tab. This reduces the number of correlations, but it requires precise tuning of your receiver.
Note: During transmission, it's ok to have 100 % buffer usage, because the buffer must contain a full WOLF data frame (= 96 seconds of audio samples). When the buffer usage reaches 0 % during TX, the frame has been transmitted completely. But a TX period will usually consist of more than one WOLF data frame.
Configuration and Calibration
Most of the configuration parameters can be set on the WOLF Config tab, a few others on other tabs. All configuration data are saved in an old-style INI-file upon exit (which can be viewed and edited with any text editor; the WOLF GUI does not use the windows registry).
In the WOLF GUI, the most important configuration parameters are set on the "WOLF Config" tab. In the list below, their corresponding command line argument names are given for reference.
Explained in one of the next chapters.
Sample rate ('r' option)
Enter the precise sampling rate of your soundcard when sending data to the output (D/A converter) here. Should be near 8000 Hz, or -better for some cards- 11025 Hz. Read the chapter about sample rate calibration to get the best out of WOLF !
Center frequency ('f' option)
Enter the audio carrier frequency here. It's advisable to use in the center of your transmitter's audio passband to reduce phase errors. For "SSB"-transmitters, use a relatively high frequency, so the unwanted audio harmonics are outside of the transmitter's passband.
Output attenuation ('a' option)
Used for testing purposes. You can use this option to reduce the output power (if you have a linear transmitter), or deliberately decrease the signal-to-noise ratio.
Phase reversal time ('t' option on transmit)
Specifies the transition time for a phase reversal, in bit times. The value must be between zero and one, inclusive. If not used, a transition takes about 0.1 bit times. Larger 't' values greatly reduce the required spectrum, at some expense in received S/N. For the same PEP, 't 1' is about 1.5 dB worse than 't 0'. Spectra for these values are shown in Stewart's original WOLF documentation.
See transmit option, but here for reception (A/D conversion). It's hard to believe, but several soundcards have slightly *different* sampling rates for in- and output (otherwise we wouldn't need this edit field).
Similar as for transmission. But for receive, you may want to use your "CW" narrow-band filter, which usually has a center frequency between 650 and 800 Hz.
Slew rate (Hz per second, 'w' option)
Frequency tolerance ('t' option on receive)
Number of frames per decoding period
Allows to limit the time for a reception attempt. After this time, the decoder may be restarted to begin an "all-new" RX-run.
Restart decoder when finished
For RX/TX control of the transmitter, either use the VOX of your transceiver, or use the serial port (RTS = Request To Send is used to activate the PTT, like in many other amateur radio programs). Select the proper COM port on the I/O Config tab. There is also a test function for the PTT control line.
Unlike some of my other programs, the WOLF GUI is a well-behaving windows application which does not use direct register access for the serial port chip. For this reason, the RX/TX control may even work with a USB/RS-232 converter.
You can select the soundcard used for input (reception) and output (transmission) on the I/O Configuration tab if you have more than one soundcard installed in your PC (or connected to the PC via USB, which is quite common these days). By default, the WOLF GUI uses the default soundcard (sic..) .
Calibrating the soundcard's sample rate
Calibrating the soundcard's sampling rate is important. If you already know the exact sample rate of your soundcard from another program, enter it in the configuration tab as explained in the previous chapter. Otherwise, you will need a precise audio reference signal. This can be an audio frequency generator with built-in frequency counter (accuracy better then 0.1 Hz), or a crystal oscillator followed by a frequency divider (for example, use a 10-MHz XO and a 12- to 14-stage binary counter like the old CMOS 4060. Pin 2 = Q13 will produce a square wave at 10 MHz / ( 2 power 13) = 1220.703125 Hz).
Another very precise reference signal is the LORAN chain, if you have an AM(!) receiver which may be tuned to 100.0 kHz. In AM, you don't need a stable VFO in your receiver (unlike CW or SSB). Depending on the group repetition interval (GRI) of the nearest LORAN chain in your area, there will be stong components in the audio(!) spectrum near 1 kHz and 2 kHz because the LORAN pulses are 1 ms long. One example for the Sylt transmitter chain (GRI = 74990 usec):
Audio frequency of the 150-th harmonic : 150 / 74990 usec = 2000.26670 Hz
Audio frequency of the 151-th harmonic : 151 / 74990 usec = 2013.60181 Hz
Observe both frequencies in the spectrum display. Their amplitude should be almost equal (otherwise you are listening to the wrong signal). Furthermore the next spectrum line (from another chain) should be several Hz away from the reference signal.
To calibrate the sampling rate, enter the precise frequency of your reference signal in the "Carrier Frequency" field (for TX) on the WOLF Config tab. Then start the frequency measurement ("Mode".."Frequency Measurement"). Observe the peak frequency on the tuning scope (if there is only one peak), or look at the decoder output. The "f:"-value in the decoder window must be added to the carrier frequency. Example: Carrier frequency set to 2000.26670 Hz (150-th audio harmonic of LORAN SYLT), decoder output = "t: 96 f: 0.004 a: 0.5 dp: 36.4" -> measured audio signal at 2000.26670 PLUS 0.004 Hz = 2000.27070. This value must be entered when the program asks for the "DISPLAYED frequency". Alternatively, you can copy the last displayed "f:"-value (0.004 in this example) into the input box. Don't forget the sign if its a negative offset ! If the value entered is less than 10 Hz, the program will automatically add the carrier frequency (it assumes you entered a frequency offset instead of an absolute audio frequency in that case).
The program will then calculate the new sampling rate and show it in a message box. If you think it's reasonable, click "Ok". The new sampling rate will be written into the edit field of the configuration tab. Now start the frequency measurement again for a few minutes. The "f:"-value in the decoder output should be constantly zero from now on. If not, repeat the above procedure. If the calibration of the sample rate is ok, you are ready for the next step: Measure the frequency error of the local oscillator in your LF receiver.
Note: Telling the 150-th harmonic from the 151-th harmonic may be a bit tedious. John, W1TAG, has written a nice article describing the calibration of the sample rate by measuring the base frequency (fundamental) of the Loran GRI; for example 1 / 74990 usec = 13.33511135 Hz (for the Sylt transmitter). John's article is here: http://www.w1tag.com/WOLFSamp.htm . This article also contains a table of Loran frequencies worldwide.
After calibrating the soundcard's sampling rate, you may need to know the
frequency error of your LF receiver - unless it has a very stable frequency
reference. For example, you want to receive a WOLF signal on 137.4410 kHz.
The LF receiver runs in USB, tuned to 135.8 kHz, so the audio "carrier" frequency
should be 1641.0 Hz ... but is this precise enough ? A weak LORAN line
in the vincinity of the operating frequency can be used to detect the
frequency error (offset) of the longwave receiver.
Note: There is a table with all LORAN lines (frequencies) in the 136 kHz amateur radio band on G4CNN's website.
For example, one of the sidebands from the LORAN-C transmitter at Sylt is at 137585.011335 Hz. A receiver tuned to 135.8 kHz (in USB) will produce a weak audio signal near 1785.011 Hz. The WOLF decoder can lock to this frequency in frequency measurement mode, if its within the tolerance range (like +/- 1 Hz). So, for this example, enter "1785.011" in the Carrier Frequency field on the WOLF config tab, then select "Mode".."Frequency Measurement" from the main menu. Let the decoder run for a few minutes, and observe the "f:"-display in the output window. If the "f:"-value is positive, the received audio frequency is too high, which means your (USB-) receiver is too low in frequency. To compensate this without retuning the LF receiver, add the "f:" value to the audio carrier frequency which you want to receive later. For example, if the frequency test run with the LORAN-line shows "f: 0.126" in the decoder output window, enter 1641.126 (Hz) instead of 1641 in the Carier Frequency field to decode the signal on 137.4410 kHz later.
The original WOLF implementation by KK7KA sends 10 symbols per second. 5 of these symbols carry "data" bits, the other 5 bits contain a pseudo-random sequence for synchronisation. So a 10-symbol-per-second WOLF signal occupies the same -3-dB-bandwidth like a classic BPSK signal at 10 bit/second. But it sends 5 "data"-bits per second. In the WOLF GUI, this original WOLF speed will be called 'normal' speed.
In November 2005, a few slower and faster variants were added. The slower variants may help for extremely weak signals. At the time of this writing, the following speeds were implemented in the WOLF GUI :
Normal speed: 10 symbols per second ( 5 data- and 5 sync-bits as explained above). One frame = 96 seconds; copy may be possible after 24 seconds.
Half speed: 5 symbols per second. One frame = 192 seconds = 3' 12" .
Quarter speed: 2.5 symbols per second. One frame = 384 seconds = 6' 24" .
Double speed: 20 symbols per second ("Fast"). One frame = 48 seconds.
Fourfold speed: 40 symbols per second ("Turbo"). One frame = 24 seconds; copy may be possible after 6 seconds.
The WOLF speed setting can be changed through the "Mode" menu.
Please note: On a crowed band (if the amateur radio LF is ever crowded), avoid the "Fast" and the "Turbo" mode, or -at least- use a longer transition time for the phase reversals (the old 't' option) of at least 0.5. The "fast" modes are not for "extremenly" weak signals -just for weak signals- but they may prove helpful to explore short propagation lifts.
A short off-air test, with the same amount of added white noise (but no matched filter), produced the following output:
2005-11-20 20:49:03 >WOLF40 -r 8000 -f 800 -t 1.0 -w 0.0000 t: 6 f: 1.016 a: 1.1 dp: 74.2 ci:10 cj:229 OYN85B1H1D6/ EB ? t: 12 f:-0.940 a:-0.8 dp: 70.6 ci: 9 cj:171 UF14XURBJYAW R4 - t: 24 f: 0.725 a:-1.5 dp: 66.4 ci: 3 cj: 78 4XB???E1FY.P6HW ? t: 48 f:-0.039 pm:4.888 jm:656 q:-13.5 -5.8 ???OCDEU1IHKMS3 - t: 72 f:-0.039 pm:5.144 jm:656 q:-11.1 -8.0 3BWF9TQQC8NOTYX ? t: 96 f:-0.977 pm:5.440 jm:573 q:-10.2 -6.7 RY.XKL*B7F9ACJY ? t: 120 f: 0.078 pm:6.431 jm:500 q: -6.4 -8.4 1SC2Z 1HCU6X6 V ? t: 144 f:-0.312 pm:7.180 jm:661 q: -8.7 -8.1 AXOQ2*CBSU5A4HE ? t: 168 f: 0.117 pm:8.691 jm:334 q: -8.6 -9.0 5CGSOVHS7UFY4F9 ? t: 192 f: 0.117 pm:9.434 jm:500 q: -3.8 -4.2 QUICK BROWN FOX - 2005-11-20 20:54:03 >WOLF20 -r 8000 -f 800 -t 1.0 -w 0.0000 t: 12 f:-0.918 a: 0.9 dp: 77.9 ci:14 cj: 1 SL.VNFZ9XGJW??? ? t: 24 f:-0.813 a: 0.2 dp: 75.3 ci:15 cj: 1 6MJ5LCDRDV/Q6/ ? t: 48 f: 0.404 a:-1.4 dp: 73.2 ci: 8 cj:278 6KJWQ/LH/ORUZJV ? t: 96 f: 0.098 pm:11.31 jm:911 q: -9.5 -8.7 /SMVNYN/C9NO9UH ? t: 144 f: 0.098 pm:18.30 jm:911 q: -7.8 -8.2 PJDQ ZJJ6 /XIA ? t: 192 f: 0.098 pm:27.44 jm:911 q: -5.5 -5.6 QUICK BROWN FOX - 2005-11-20 20:58:19 >WOLF10 -r 8000 -f 800 -t 1.0 -w 0.0000 t: 24 f:-0.239 a:-0.9 dp: 86.7 ci: 6 cj:395 POGB K994ALPMSK ? t: 48 f:-0.750 a:-0.8 dp: 82.8 ci:12 cj:377 RDR 5KBDPD1 ??? ? t: 96 f:-0.244 a:-0.6 dp: 78.7 ci: 4 cj:154 8X OX6C4*/KIRQD ? t: 192 f: 0.098 pm:26.50 jm:941 q: -7.8 -9.1 V448*F0A6CNEF5. ? t: 288 f: 0.098 pm:53.36 jm:941 q: -5.2 -3.4 QUICK BROWN FOX -
It's interesting to see that under these identical SNR conditions, the 'fast' modes were not worse than the 'normal' mode (except for the occupied bandwidth of course). A matched filter may improve the performance of the slower modes, but such a feature has not been implemented yet.
The "QSO mode" may help in attempted two-way contacts in WOLF BPSK mode. If you have used WSJT, or are familiar with EME procedures on VHF, this may sound familiar. In QSO mode, the program periodically toggles between transmission and reception, synchronized to the beginning of an hour.
Both stations must agree on 'synchronized' transmission and reception.
As a suggestion, use 15 minute intervals for transmission or reception (maybe
30 minutes will turn out to be a better choice for trans atlantic QSO attempts,
a discussion on the RSGB LF reflector may show who uses which interval, and
on which frequency..).
The QSO-mode parameters must be defined on the WOLF Config tab :
Period : defines the RX- or TX- period length in minutes. Typically 15 or 30 minutes (or 5 minutes for "local tests"). For the following examles, assume the period is 15 minutes.
My TX period: defines in which period you transmit (beginning at
the full hour, regardless of how long a period is).
"first" means transmit in the first period, for example from 22:00 to 22:15, then receive from 22:15 to 22:30, then transmit from 22:30 to 22:45, and so on.
"second" means transmit in the second period, for example from 22:15 to 22:30, then receive from 22:30 to 22:45, then transmit from 22:45 to 23:00, etc.
Suggestion: Let the CQ-calling-station use the first period, and the answering station transmit during the second period by default - regardless of the station's geographic location or the antenna direction ( since most of us don't use beams to transmit on LF... ).
Remaining TX-overs until stopping own
This parameter is -more or less- an emergency brake to protect you against endless transmission. When a a new transmission starts, this counter is checked and decremented. If this counter is zero, transmission won't start. This counter can also be set to a certain value after receiving a certain text with the "auto-answering machine" (see next chapter). For example, the answering machine may set this counter to one ("tc=1") after receiving the final over from the other station, to send one final over with "73" or similar and then stop all transmissions.
To start a QSO, type a CQ call in the TX message (on the main screen), and enter QSO mode by selecting "Mode"..."QSO mode" from the main menu.
If your TX-period has already begun when entering QSO mode, the transmitter will be keyed up immediately. Otherwise the program remains in receive mode, until it's time to transmit.
If the TX message (on the main tab) is empty, transmission won't start
If the "remaining TX-overs" have been counted down to zero, transmission won't start
While receiving, watch the decoder output, and -if you're lucky and someone answers your call- type an answer in the TX message field before your next TX interval starts. The transmitted message won't change while transmitting ! If you came back into the shack just a few seconds too late, and find yourself transmitting the wrong message, stop the transmitter (Mode..Stop), enter the text you want to send, and enter QSO mode again. A few seconds of your TX-over will be missing then, but this is not a problem because the WOLF message is repeated a few times anyway.
When the QSO is complete, switch back to Receive Only in the mode menu or start another CQ call (don't forget this; the WOLF GUI is rather stupid, it doesn't know when a QSO is finished, and would keep on sending in your TX-periods until the fuses blow..).
On the "RX / TX Message" tab, some special messages can be defined which will be compared with all received (and successfully decoded) messages. This feature can be used to...
trigger alarms (to wake up the operator if a certain message has been received)
to make half-automated operation possible, while the operator off for a short time
send some feedback to a station which transmits an interrupted "overnight" beacon signal
To define the message strings, and to enable or disable the automatic answering function, switch to the "RX / TX Messages" tab :
Letters in lower case are macros (placeholders) which may be defined in the upper part of this tabsheet. If the "dxcall" field is empty, the program will automatically set it to the received string. For example, if the message "CQ WD2XES K" was successfully decoded, it will match the predefined RX-message "CQ dxcall K". If the "dxcall"-field is still empty at that time, it will automatically be set to the received letters (here: dxcall will be set to WD2XES). After that, the "dxcall"-macro will be automatically replaced during transmission (but not in the definition table). The "dc"-macro produces a short form of the "dxcall" (=two last letters from the suffix), the "mc"-macro expands into your own two-letter suffix.
You don't have to use the auto-answer machine if you think it's nonsense. The author wasn't sure if it makes sense at all, but it may be helpful on a few occasions. Having two machines talking to each other via LF link may be fun, but it's not what most LF operators consider a valid QSO.
Never leave your station transmit unattended if your license doesn't allow it.
As long as the "auto-answer" checkmark is not set, the received messages are compared with the "RX" strings (left column), and trigger alarms if enabled, but will not start any transmission or modify the transmitted message.
If the "auto-answer" function is enabled, and "mycall" is defined, and the "dxcall" field is set (either manually or because a matching CQ-call has been decoded), the auto-answer function will activate the QSO-mode. So make sure the QSO-mode parameters are properly set !
The "alarm bell" is the DTR signal on the serial interface ("Data Terminal Ready" on COM1..COM8, see I/O-Config). The bell is not an audio signal for the soundcard, because the soundcard will most likely be connected to the transmitter, and sending "ding-dong" on LF may be illegal in your country ;-). Connect a transistor, relay, and a ringer or a signal lamp to the serial port.
Though WOLF now has a graphic user interface, it is still possible to invoke
the program with all parameters in the command line. This is very helpful
for off-air testing, using wave files with signals and artifical or recorded
noise (see below, -a option).
The syntax is exactly the same as in the original console application. A detailed description of all command line parameters are in Stewart's original description of WOLF. Here just an essay:
|-a||dB||set attenuation of test data below noise|
|-b||set noise blanker|
|-c||set coherent averaging|
|-e||-||set eight bit mode (for WAVE file)|
|-k||-||set keyed (xor gate) mode|
|-l||-||look at last frame only for freq and pos|
|-m||set measurement interval|
|-n||set frame count (serial mode)|
|-o||set binary options (octal bit combination)|
|-q||specify name of signal file|
|-r||Hz||specify actual sample rate|
|-s||specify number of samples to skip|
|-t||Hz||specify frequency tolerance (on rx)|
|-t||0 to 1||specify phase transition time (on tx)|
|-v||set verbose mode|
|-w||Hz / second||set slew rate|
|-x||"15 characters"||specify message to transmit|
(Ok, I hate this paranoid stuff, but someone told me it's wise to have it here..)
THIS SOFTWARE IS PROVIDED ''AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
AUTHOR AND CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE.
Namings for products in the software and this manual, that are registered trademarks, are not separately marked. The same applies to copyrighted material. Therefore the missing (r) or (c) character does not implicate, that the naming is a free trade name. Furthermore the used names do not indicate patent rights or anything similar.
WOLF was developed by Stewart Nelson (KK7KA). The graphic user interface was written by Wolfgang Büscher (DL4YHF).
The program must not be used in 'critical' environments, where program failure may cause harm to persons or damage to property. Dont rely on this program as an emergency communication medium !
Further restrictions to the use of WOLF may apply, please check Stewart's website too !
Last modified: 2013-02-17 (YYYY-MM-DD)