VLF,
Finally there was a decode from my 3 character message that i transmitted during the last 6 nights!
It was a bit strange, the 1 char message and the 2 char message was decoded after one night each. So 3 characters should decode in 2 or maybe 3 nights, but not longer. But there was no decode even after 4 or 5 days. Something must have been wrong.
Background: Spectrum Lab corrects the drifting sample rate using a reference signal, like the PPS pulse from the GPS module. The sample rate is measured and corrected each second when PPS is used. Usually the deviation between 2 measurements is smaller than +-1 ppm. But at RC4HAA it was +-30 ppm. The PPS pulse is usually a rectangular pulse with a width of 200 ms or less. At RC4HAA the pulse is differenciated, probably by the soundcard, i.e. it is a positive and a negative short pulse of a few us length. I concluded that this not proper looking pulse caused the high sample rate jitter. SpecLab calculates the average sample rate out of the last 60 measurements. I took this average value and put it into the 'calib table'. One can define a maximum deviation. It is assumed that the sample rate will not drift more than average +- max. deviation. Each value outside that max. deviation must be a false reference signal that will be ignored then. i.e. the sample rate will not be corrected by this value. I choose a small max. deviation of +-2.5 ppm only and expected that this will lower the jitter!
But my assumption was wrong. In fact the PPS seems to work quite well, despite the suboptimal shape of the pulse. The high sample rate jitter seems to come from the PC itselfe so the sample rate correction was working quite well, showing and correcting the high jitter each second. So i made things worse by reducing the max. deviation!
After 3 nights of transmission i came to that idea and started a second SpecLab instance to export txt files for EbNaut detections. The settings were equal, just the max. deviation was set to +- 20 ppm now!
During these 6 days i worked out how to use the -f16 option in vlfrx tools by Paul. When running the decoder with this fuction, it will tell you how deep the message is buried in each of the files (each night one).
On saturday morning i quickly saw that with the 20 ppm deviation produced an Eb/N0 of -4.1 dB from a single (noisy) night. This confirmed the assumption that 20 ppm will do a much better job than 2.5 ppm. It also became obvious that a 3 character message can be decoded after 2 nights, if the noise isn't to high. This was expected from the results of the 1 and 2 character message. The change to the small max. deviation was done after the 1 and 2 character message.
Yesterday morning i lost the access to the RC4HAA PC. It took until the late night until i got the information about the new temporary password for Teamviewer. During that time, the 6th (3rd with the 20 ppm setting) transmission was already running. But i already got a decode with just 2 transmissions. The second file (18th Nov) showed 3.95 dB less noise, so the improvement was more than 3 dB.
Now this morning i had 3 files to stack and, as expected, the decode is even better.
A screenshot of the decoder and the decoder log file is in attachment. The message is the new longest one on 8270 Hz over the 2877 km land path. 3 characters in 38 hours and 24 minutes.
My next and last goal for this year on that path is a 5 character message. It will start this early evening. A separate announcement will follow.
73, Stefan
