I have here two versions of the original WOLF command-line program:
0.51 and 0.61 - apparently there is also a version 0.62 which is used
by the GUI program.
I wanted to duplicate what Stefan did using the GUI version: generate
a signal on 8970 Hz using 24000 s/s. It *seemed* to work OK but when
I examined the sound card output signal with Cool Edit, the frequency
was way low - about 8241 Hz instead of 8970. So I went back to the
original command line programs. I found that versions 0.51 and 0.61
apparently worked, generating 2,304,000 audio samples (exactly 96
seconds at 24000 s/s) to a file called WOLFX.WAV. Unfortunately the
samplerate in the .wav file header was coded as 8000 s/s, which means
if we played it back it would run for 288 seconds and the audio
carrier frequency would appear at 2990 Hz. So I went in and manually
changed the s/s field in the wav header to 24000 s/s. Then the file
worked OK. I was able to decode the message by mixing the 8970 Hz
down to 800 Hz and decimating the sample rate to 8000 s/s. Turning
again to the GUI version, I asked it to encode a .wav file at 24000
s/s with a carrier freq of 8970 Hz. It reported version 0.62 and
everything OK. However, when I examined the WOLFX.WAV file so
created, its .wav header said the samplerate was 22050 s/s instead of
24000 s/s! That explains why the real-time GUI uutput seemed low in
frequency: 8970 * 22050 / 24000 = 8241.1875 Hz. The upshot is we
need to manually check the wav header and set the s/s field to 24000
instead of whatever else it might say. And furthermore, don't trust
the real-time Tx soundcard output signal frequency with the GUI
version, especially when using odd-ball sample rates and high output
frequencies which may never have been tested. Be aware that WOLF
generates envelope-shaped audio, so it might be more difficult to
convert it to a clean square wave to drive a Tx, especially near the
phase transitions where the amplitude drops down to zero.
73,
Bill VE2IQ
|
