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
Am 14.11.2017 17:07, schrieb DK7FC:
VLF,
Tonite, a new attempt to leave a 3 char message at RC4HAA and an
invitation to newcomers:
f = 8270.1000 Hz
Start time: 14.November.2017 16:00:00 UTC (daily)
Symbol period: 60 s
Characters: 3
CRC bits: 10
Coding 16K21A
Duration: 12:48 [hh:mm]
Antenna current: 650 mA
73, Stefan
PS: The sun is back, the grabber is back! :-)
|
RC4HAA_8270_3characters.png
Description: PNG image
171819-log.txt
Description: Text document
|
