Message-ID: <2088.200104051422@gemini>
From: "James Moritz" <j.r.moritz@herts.ac.uk>
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
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Sender: <majordom@post.thorcom.com>

<?color><?param 0100,0100,0100>Dear LF Group,<br><br>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.<br><br>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.<br><br>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.<?/color>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. <br><br>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.<br><br>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.<br><br>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!<br><br>Cheers, Jim Moritz<br>73 de M0BMU<?color><?param 0100,0100,0100><br><br>