Return-Path: Received: (qmail 19326 invoked from network); 5 Apr 2001 14:33:36 -0000 Received: from unknown (HELO warrior-inbound.servers.plus.net) (212.159.14.227) by excalibur.plus.net with SMTP; 5 Apr 2001 14:33:36 -0000 Received: (qmail 20165 invoked from network); 5 Apr 2001 14:33:29 -0000 Received: from unknown (HELO post.thorcom.com) (212.172.148.70) by warrior with SMTP; 5 Apr 2001 14:33:29 -0000 X-Priority: 3 X-MSMail-Priority: Normal Received: from majordom by post.thorcom.com with local (Exim 3.16 #2) id 14lAev-0007hT-00 for rsgb_lf_group-outgoing@blacksheep.org; Thu, 05 Apr 2001 15:22:49 +0100 Received: from hestia.herts.ac.uk ([147.197.200.9]) by post.thorcom.com with esmtp (Exim 3.16 #2) id 14lAes-0007hO-00 for rsgb_lf_group@blacksheep.org; Thu, 05 Apr 2001 15:22:47 +0100 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Received: from [147.197.200.44] (helo=gemini) by hestia.herts.ac.uk with esmtp (Exim 3.16 #4) id 14lAeS-0001n4-00 for rsgb_lf_group@blacksheep.org; Thu, 05 Apr 2001 15:22:20 +0100 Message-ID: <2088.200104051422@gemini> From: "James Moritz" Organization: University of Hertfordshire To: rsgb_lf_group@blacksheep.org Date: Thu, 5 Apr 2001 15:22:16 +0000 MIME-Version: 1.0 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 8bit Subject: LF: [TECH] IK5ZPV received yet again X-Mailer: Pegasus Mail for Win32 (v3.11) Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group Sender: Dear LF Group,

I made 3 .wav file recordings on 137.5kHz between 2030 and 2200 last night. All three recordings decoded without problems within 1 or 2 frames of data, so clearly plently of margin yet - the BPSK signal was also just about visible on the spectrogram. I would reckon a 10dB reduction in TX power should be feasible. Wolf indicated the frequency stayed around -0.4Hz below the nominal value.

Re G3XDV's comments - It's certainly true that Wolf in it's present form is not particularly "user friendly" - I think most of the numbers it generates are basically diagnostics for the benefit of the programmer (bear in mind KK7KA describes his program as "a demonstration"). However, the f: column indicates the apparent difference in audio frequency (Hz) between the signal being decoded, and the nominal frequency set using the -f parameter in the command line. The jm: column indicates the timing offset between the TX and RX, and should remain constant within +/- 1 when things are set up properly, and a signal is being received. pm: is suggested as an indicator of signal strength, although it seems not always to give a very meaningful figure. None of these figures have much meaning if a signal is not actually being decoded, which limits their usefulness for setting-up purposes.

There are basically 2 variables that must be set up properly for the program to decode successfully. The most important is the -r correction for the sampling rate of the soundcard. The soundcard sampling rate affects both the apparent frequency of the signal as seen by the software and the timing of the data bits.If you think of the soundcard as a tape recorder, the -r value would be the exact speed at which the tape is running. The Wolf software needs to know this so it can 'replay' the recorded data at the correct speed. For example, if Wolf thinks the sample rate is 8000 samples/s but it is really 7950 samples/s, Wolf will be replaying the tape too fast, and the apparent frequency of the signal will be higher, and each data bit in the signal will be of shorter duration. So it is essential to have the -r correction for your soundcard before any other settings can be meaningfully determined.

The second variable is the -f switch which corrects for the frequency offset between TX and RX. There is potential for confusion here, because one can chose a value for -f that will offset the frequency error caused by the incorrect sampling rate, if this has not already been corrected. Although this will make Wolf see the right signal frequency, it will not correct the error in the bit timing caused by the sampling rate error. Wolf can cope with modest uncorrected frequency errors, such as up to 0.5Hz. I ususally set the -t frequency tolerance option to 1 Hz.

The bit timing is much more critical to Wolf than to other types of BPSK software, because Wolf aims to decode a noisy signal by looking at a very long run of a repeated message (up to 1536 seconds at 10bits/s = 15360bits); compare with Coherent ET1 mode, where each character is encoded separately as 16 bits in 1.6 seconds. In order to prevent the transmitted bits at the end of the run of data getting out of step with where the receiver is expecting them to be, accurate timing is required at both TX and RX ends. So, for example, in order to prevent TX and RX from getting out of sync by more than 0.1 bit periods in a run of 15360bits, it is neccessary to have the combined sample rate error of TX and RX less than (0.1/15360 x 8000 samples/sec) = 0.05 samples/sec, or about 6 parts per million. This problem can be overcome to some extent by using the -l command line switch, which causes Wolf to operate only on individual 960 bit long frames of data - but it also means the full signal recovery properties will not be obtained.

Methods of cal ibrating the sample rate were discussed some time back on the reflector - it is a pain to do, but once done it should not be neccessary to repeat often in the life of the soundcard, although I have doubts about whether a soundcard clock oscillator can be expected to maintain precision in the ppm range over an extended period. Personally, I think this is a good reason to move away from soundcards towards purpose-built "radio" A/D interfaces like the VE2IQ/G4JNT designs, where one has direct control over the sample rate. But then, I am not writing the program!

Cheers, Jim Moritz
73 de M0BMU