<?color><?param0100,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><?param0100,0100,0100><br><br>
|
