VLF,
Here's the summary of the experiment we started more than 2 weeks ago.
Jay/W1VD and Garry/K3SIW tried to decode my 5 character EbNaut
message transmitted on 8270.1 Hz. Thanks to them for their continuous
interest in this experiment. We have now an interesting set of data to
analyse.
The transmission took 7.25 hours each night starting February, 25th.
Last night there was no contribution to the stack because my TX stopped
after a short time, due to a too much detnued antenna (heavy rain). So
all in all there are 14 files to weight and stack, in the hope
to get a decode from the stacked file.
Jay and Garry sent me txt files daily. They contain the exported FFT
from SpecLab and can be converted into wav files using Markus' tools.
They have been weighted by the square of the noise amplitudes and have
been stacked afterwards. Since i am the transmitting station i know the
message. Using Paul's ufb vlfrx tools i can reconstruct the carrier and
determine it's SNR from the daily files and also for the stacked file.
I saw which day improved the SNR of the stack and which day reduced the
SNR, but i must not tell these details to Jay and Garry because if
they weight their stack based on this information, it would not be a
valid decode any more.
Actually a valid decode can be produced not only by the RX station, it
can be produced by everyone. Paul or Markus or Stefan can produce a
valid decode of Jay's files but we must not use informations that Jay
can't know before knowing the message. All we can use to improve the
stacking gain is the noise amplitude and eventual known time offsets
caused by the TX or RX stn.
Here are the wav files from Jay and Garry:
http://www.iup.uni-heidelberg.de/schaefer_vlf/VLF/wav_files_W1VD_K3SIW.zip
For those who want to try to reproduce the results: Note there is an
additional time offset of 0.3 sec from the TX side (SpecLab) and 4
samples from the RX side (SpecLab).
For W1VD files the time offset should be 198.3 seconds. For K3SIW it
should be 216 seconds.
Here are the details from Jay's files, to get an overview:
| day |
rms amplitude |
weight,+-dB |
SNR / dB |
SNR of stack |
| 26 |
5.83e-9 |
0 |
3.65 |
3.65 |
| 27 |
6.99e-9 |
-3.15 |
0.44 |
3.95 |
| 1 |
6.81e-9 |
-2.7 |
1.82 |
3.98 |
| 2 |
6.13e-9 |
-0.87 |
2.13 |
6.11 |
| 3 |
8.20e-9 |
-5.93 |
3.54 |
7.70 |
| 4 |
8.69e-9 |
-6.93 |
-3.38 |
7.07 |
| 5 |
1.26e-8 |
-13.43 |
-1.39 |
7.46 |
| 6 |
1.00e-8 |
-9.37 |
-0.09 |
8.14 |
| 7 |
7.48e-9 |
-4.33 |
4.53 |
9.4 |
| 8 |
1.50e-8 |
-16.44 |
4.67 |
9.18 |
| 10 |
6.90e-9 |
-2.93 |
-11.57 |
8.66 |
| 11 |
1.88e-8 |
-20.29 |
-4.67 |
8.82 |
| 12 |
9.41e-9 |
-8.32 |
-6.8 |
8.49 |
| 13 |
1.04e-8 |
-10.09 |
-3.59 |
7.99 |
| W1VD,
FN31LS, QRB: 6096 km |
|
|
| SNR
reported by vlfrx tools |
|
|
| stack
26/27/01/02/03/05/06/07: +10.58 dB |@ -T197 |
|
Sometimes, a time offset of 197 seconds produced a better result.
And here are the results from the files of K3SIW:
| day |
rms amplitude |
weight,+-dB |
SNR / dB |
SNR of stack |
| 26 |
1.74e-8 |
0 |
-9.78 |
-9.78 |
| 27 |
1.24e-8 |
5.89 |
-7.77 |
-9.23 |
| 1 |
1.11e-8 |
7.81 |
-3.32 |
-14.17 |
| 2 |
1.27e-8 |
5.47 |
4.03 |
0.19 |
| 3 |
8.82e-9 |
11.84 |
-1.35 |
0.70 |
| 4 |
1.46e-8 |
3.05 |
5.58 |
4.63 |
| 5 |
2.35e-8 |
-5.22 |
6.91 |
6.00 |
| 6 |
2.44e-8 |
-5.87 |
-11.85 |
5.44 |
| 7 |
1.53e-8 |
2.23 |
-3.46 |
5.08 |
| 8 |
1.73e-8 |
0.1 |
5.77 |
6.35 |
| 10 |
1.59e-8 |
1.57 |
5.54 |
7.88 |
| 11 |
3.05e-8 |
-9.75 |
-9.92 |
7.73 |
| 12 |
1.57e-8 |
1.79 |
-5.55 |
7.58 |
| 13 |
1.77e-8 |
-0.3 |
-4.17 |
6.81 |
| K3SIW,
EN52TA, QRB: 7048 km |
|
|
| SNR
reported by vlfrx tools |
|
|
| stack
02/04/05/08/10: +11.31 dB in 38.3 uHz (just 5 days!) |
Now, i got no decode of the message even when running the decoder at a
list length of 5E6. The best Eb/N0 shown was -3.2 dB for the stack of
K3SIW.
BUT! I think there is some hope
that we still might decode the message, even based on informations
available to the RX site, i.e. a valid decode:
Our weighted stacking is based on the square of the rms amplitudes of
each day. This is the way of stacking in add.exe by DF6NM and i think
it is similar in the Linux stack script by Paul.
These amplitudes are calculated based on the full length of the
recording / wav file. It is an average value. There can be times of
very high QRN, e.g. a local thunderstorm, at the beginning of the file
and then a quiet night for 80% of the transmission. Anyway the reported
noise amplitude will be very high and so the file/night is downweighted
in the stack. The wav files generated by SpecLab are almost 10 hours
long, whereas the transmission takes just 7.25 hours. So first it would
make sense to cut the time at the end so it does not contribute to the
noise calculation. In vlfrx tools this can be done, for example,
vtwavex 05.wav | vtcat -T2018-03-04_22:30 -E26200 | vtcat -p > 05.vt
But this will not cause a big difference.
The main improvement will come from a individual pre-processing of each
file. The signal must be analysed in the time domain and the amplitude
must be normalised before the files become weighted and
stacked. This way the high noise from the local thunderstorm would be
downweighted within the file. This should improve the SNR significantly.
In the attachment there is an example. Two days of the files of W1VD.
Both of them have a good contribution to the stack. In the night 07/08
of March there must have been strong QRN in the first 3 hours but then
it was a very quiet night. Due to the heavy noise in the beginning of
the file, the whole night was downweighted by -16 dB in the stack,
although it is one of the best night in the stack!
The other day was quiet at the beginning, then the QRN became higher in
the morning. The last 2.5 hours have a relatively high QRN although the
transmission is already completed, so here it would help to cut the
time that is not required and calculate the the noise amplitude then!
Now, what we need is a tool that applies a danamic amplitude gain (up
or down) within the file. Paul and Markus are the ones that can program
something. I have just some basic ideas how to do it. I would take the
challenge but i am not sure if my idea would work. I would use vtstat
to determine the mean amplitude in 1 minute intervals (like in the
attachment). This is already based on some advice by Paul BTW :-) Then
i would look at the average noise within the whole transmission time.
In SpecLab this is done by sorting the bins by their noise amplitude
and adding 3 dB to the value at a level after 75% of the bins. Based on
this, a scaling factor can be calculated. Each bin will then be scaled.
In a loop, the segments can be selected and scaled and then put
together again (using the 'cat' tool)...
Here is room for discussions and ideas.
I bet, with further new techniques we will manage to decode the message
from the files by W1VD and K3SIW.
73, Stefan
Am 13.03.2018 18:57, schrieb DK7FC:
VLF,
After more than 2 weeks, the 5 characer message has been transmitted
nearly each night! Tonite will be the last night.
W1VD and K3SIW are collecting files since the 26th. There is a stack of
15 nights available now!
So far there has been no decode, neither by weighting the stack based
on informations known by the RX side nor by by weighting/aligning the
stack based on informations known by the TX side.
However, the reconstructed spectrum peak reaches > 10 dB on both RX
stations. The final optimum SNR will be reported tomorrow.
5 characters should have been made in a much shorter time, based on
what we saw from the 2 character decode by W1VD. But the QRN insreased
significantly since then. Another reason is the quickly shorter getting
nighttime. The beginning and the end of the message is already in
daylight now and so the terminator messes up the phase in the stack,
reducing the stacking gain.
For Eb/N0 = 0 dB we need 14.5 dB SNR, so there is no hope, except i
would use a kite again and add 10 dB ERP!!!! :-)
We will see how things go on 17.47 kHz on the same paths. I will be on
air there in 2 days, starting attempts to be detected in VK7.
73, Stefan
Am 25.02.2018 23:17, schrieb DK7FC:
Hi Jay, VLF,
A great success again! Thanks for your efforts on the RX side. And
congrats to that result!
It was exciting and interesting to follow the rising Eb/N0 and the
daily variations when using the -f16 function in the Linux decoder.
It can be quite an effort to tweak out the last 0.05 dB in the hope to
find the correct message then, by varying time offsets and weighting. I
am learning a bit more each time i follow the decode process here on
the TX side by analysing the wav files you kindly provided.
We are now leaving the winter season. The QRN has been clearly stronger
during the last nights. There are regular thunderstorms in south Italy
and Greece now.
A longer message is realistic. Let us try 5 characters now:
f = 8270.1000 Hz
Start time: 25.FEB.2018 22:30:00 UTC (daily)
Symbol period: 24 s
Characters: 5
CRC bits: 18
Coding 16K21A
Duration: 07:15:12 [hh:mm:ss]
Antenna current: 700 mA
I bet you will get the result after 4 days of stacking! Let's see! Good
luck!
73, Stefan
|
W1VD_stat_0708MAR.png
Description: PNG image
|
