Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

Re: LF: EbNaut and The Cat / Take 3

To: [email protected]
Subject: Re: LF: EbNaut and The Cat / Take 3
From: Markus Vester <[email protected]>
Date: Wed, 25 Nov 2015 12:09:20 -0500
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1448471360; bh=1otCftJx74zxr/lQQQl8oMZiqBrR6fD7shY0ln2Nz/I=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=ybUoaKjLajtpdlsGxjUscqD+EBiiGXmx8d9LzvTvqU13JGgaEPE7D0l910lDFtBcQ NUcM0cZXUjr+VdmelDsa+UPnrpo602Cim7OMF0pCHIgdXr9aH6pu8S/u3HVxNs7uhn FGvwQ0xj+NviOqyIPnzvZIixYodTBQbSpjnSSp2E=
In-reply-to: <[email protected]>
References: <[email protected]>
Reply-to: [email protected]
Sender: [email protected]
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.
 
Thanks also from here to all participants (feline and human)! Next step - reduce frequency by 24.4334 dB?
 
All the best,
Markus (DF6NM)

 

-----Ursprüngliche Mitteilung-----
Von: Paul Nicholson <[email protected]>
An: rsgb_lf_group <[email protected]>
Verschickt: Mi, 25 Nov 2015 3:57 pm
Betreff: Re: LF: EbNaut and The Cat / Take 3

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
--



<Prev in Thread] Current Thread [Next in Thread>