Signal got better later, and is still visible as a blue haze in last night's TA spectrograms https://dl.dropboxusercontent.com/u/26404526/LF_old/LF_lastnight.htm .

 

All messages up to 2 UT decoded nicely:

 

start   Eb/N0  time offset
 UT       dB    seconds

2100     10.3     1.1  
2130      nil
2200      7.2     3.5
2230      8.8     4.5
2300     11.1     5.8
2330     11.2     7.0

0000     13.9     8.1
0030      8.0     9.6
0100      8.1    11.1
0130     11.6    12.0

The time offset is only approximate, and I'm not sure whether the first second is due to a lag associated with low decimated samplerate. But the average rate of delay accumulation (1.2s / 30min) is probably correct.

 

Thanks to Paul for of ebnaut-rx version 0.3d. I also think that counting all missing symbols as errors will be too pessimistic. Maybe it makes sense to assume a 50% error rate for the statistics, more equivalent to a loss of signal e.g. due to propagation. 

 

One very minor issue I noticed with the previous version is that it crashes when rerunning after having increased the message length - presumably some buffer becoming too small.

 

All the best,

Markus (DF6NM)

 

Thanks to all for the interesting tests.  But we are battling 

with clocks and oscillators rather than propagation and noise. 

 

At least with EbNaut nobody can complain that the operator is 

just installing the software and pressing 'start'.  It does 

seem like that with some modes: the computers are doing all the 

communicating and the operators are merely spectators.  Clearly 

not the case here! 

 

I cheated and used Markus' time offsets to polish my decodes: 

 

  time   Eb/N0    Phase 

  21:00    9.6    30 30 30 30 

  21:30   13.3    0 0 0 0       (offset 1.8 seconds) 

  22:00   12.0    0 0 30 30 

  22:30   10.8    150 150 180 180 

 

Quite a good signal in fact. 10dB too strong for a good test 

but without the strong signal it would have been harder to 

identify the clock offsets.  We don't seem to have a problem 

with phase with these short messages. 

 

I've updated the decoder, now version 0.3d 

 

  http://abelian.org/ebnaut 

 

It counts missing (padded) symbols as errors when calculating 

BER and that will reduce Eb/N0.  That's not really the correct 

thing to do: an erasure isn't quite like an error, the decoder 

only has to work out the missing bits, not oppose errors from 

the demodulator.   The consequence will be that instead of 

Eb/N0 being incorrectly high, it will now be incorrectly low. 

 

Eg I just tried decoding less than half the 21:30 message and 

it gave 

 

  found rank 0: TANGLES  ps [  1  180  180  180  180] 

  re-encode 322/608 ber 5.30e-01  Es/N0=-20.0 Eb/N0=-8.4 

 

Any BER over 50% is bogus and the Eb/N0 is totally meaningless. 

Nevertheless the decoder is having to fix up 322 bits here. 

 

Maybe a better thing to do is just sum over the un-padded 

symbols, but that's still not quite right.   I tried that but 

it throws up some other problems. 

 

Probably not a big deal either way.  It's unusual to have so 

much of the message missing. 

 

I did once decode a VLF message with about a third of it 

missing because I was unaware that the transmission was coming 

and the rx and PCs were down for maintenance. 

 

Just for fun I tried to see how little of the 21:30 message 

was actually needed for a decode.  It worked with 108 seconds 

of signal and 1108 seconds missing. 

 

  found rank 206730: TANGLES ps [  1  180  180  180  180] 

  re-encode 559/608 ber 9.19e-01 

 

Of the 608 transmitted symbols, 554 were missing, 5 errored, 

and 49 correctly demodulated.   Those 49 good bits were enough 

to fix the errors and erasures. 

 

This shows that an erased bit is much less distracting to 

the decoder than an errored bit.  The list decoding becomes 

very slow under these conditions due to a degenerate backward 

pass tree. 

 

-- 

Paul Nicholson 

--