Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

Re: VLF: EbNaut transmission on 8270.1 Hz again and again

To: [email protected]
Subject: Re: VLF: EbNaut transmission on 8270.1 Hz again and again
From: DK7FC <[email protected]>
Date: Fri, 29 Apr 2016 22:43:26 +0200
In-reply-to: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]>
Reply-to: [email protected]
Sender: [email protected]
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
Hi Paul,

Yes, it will be interesting. Just 4 hours are gone now, i can't await it! ;-) What about the phase of DHO38, is it useful to get a rough idea about the phase changes? For slower modes (taking more then 12 hours), could it be useful to insert non-keyed sections to make a phase check each 2 hours or so? Maybe it will be possible to develop a technique to calculate the behaviour of the terminator by watching given (msk) signals close to the transmitter, maybe even 2 or 3 of such reference signals. 12 hours is nothing! You remember my QRSS-60000 transmission, my callsign sent in 10 weeks! :-) 100 GB RAM, that's extreme. Certainly interesting but i would rather like to go a step closer to communications which are manageable for more people. During a yesterdays walk through the forest i got some ideas about a QSO/beacon config for EbNaut. But i will describe that in a separate mail/topic, following...
73, Stefan

Am 29.04.2016 22:21, schrieb Paul Nicholson:
> 27 hours will not be easy.

Indeed, four terminators to cope with.  Half the message
will have daytime phase and half night time phase and
a mess in between.  No chance of a decode if day and night
phase differs by more than 90 deg (which it probably will).

So I will have to get a nominal phase from LWPC or my
own modeling program (or just guess) and use that to EQ the
signal before decode.

An interesting challenge!  Thanks Stefan

> Start: 29.04.2016  16:00:02
> Period: 40
> Length: 45 (!)

No problem with the length, and for future tests like
this, why not run a 16K code (with half symbol period)
and with longer constraint length, eg 16K25A?  The
decoder will need about 100 Gbyte RAM for that, but
that's ok, I just use a big AWS Xeon with 36 cores and
a ton of RAM.   The extra bit of coding gain is worth it
and might make all the difference.

--
Paul Nicholson
--







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