Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

Re: LF: Slow JT9 modes...

To: LineOne <[email protected]>, rsgb_lf_group <[email protected]>
Subject: Re: LF: Slow JT9 modes...
From: Andy Talbot <[email protected]>
Date: Thu, 6 Sep 2018 14:25:23 +0100
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=HsmET993mIef73Mqc/7fBMM5E+e30R+gRiiBsGWu3Gs=; b=GHRqwL0RQjsv+2STR5l3X9kCzJKPYjv3f+ZXEb+cEC3Gpn/FhemUfUHEk0A7F2cZzE 1jVFQBSBNOKXJ8m6CTgnq5FJ2mjCPNYcZ2UC7/bk2DHKs4cHbtG07uBcB2riiuGSjMhZ IUWJ8NDLVxX0NKxtoG8PFLmrUnEF4phhXo2fMFE/tmZdqWaKXQN2QSIHqc1P/McLfhK3 a9oOy3bcDTtrva9xZZRXBmWc8Wn54npWKl2y/ZCQs6jHNftZ9zmobI3AJkZp2saX6W2v sB+2PiiQQJyxZgNzOFNaNyQbp3URP61F5FTnlp0uJwmgKwK5aQDM1PUqGd5NdNNJu1Do ra+A==
In-reply-to: <CAA8k23Qs9aRiSuKoXaEpSENOVn8wLJZav9yNiggx78Zega3yag@mail.gmail.com>
References: <[email protected]> <[email protected]> <CAA8k23Qs9aRiSuKoXaEpSENOVn8wLJZav9yNiggx78Zega3yag@mail.gmail.com>
Reply-to: [email protected]
Sender: [email protected]
And a follow-on thought ...

Wonder if a waterfall plot that shows phase of each bin as colour instead of amplitude would be any use as a simple signalling scheme
May try that with my custom LF receiver...

http://g4jnt.com/Coherent_LF_Receiver.pdf    It hasn't had a great deal of use since I built it - now may be the time to revisit


On 6 September 2018 at 14:21, Andy Talbot <[email protected]> wrote:
As good as JT9 is, in whatever speed-flavour, at LF it throws away one aspect of LF propagation that isn't not really availalble for HF, phase stability over longer periods, at least suited to a few characters.   JT9 is a purely power-based system with heavy FEC.

So while slower versions of JT9 would be good for LF in  the short term, they will not make the most of what propagation can offer.  NO one on the WSJT-X development team is interested in LF, so it's no good looking there.    However, I'm sure they'd be amenable to someone else joining the team and adding an LF users perspective and writing / developing the relevant submodes.   Or do it independently using the open-source code.  

EBnaut carries phase signalling to the extreme, carrying no sync / timing info in the on-air symbols and being completely reliant on high stability frequency sources and people accurately starting and stopping.   This complex manual setting is, in my opinion its downfall;  high stability sources are less of a problem these days as OCXOs are now so cheap and readily availalble.

What we need is an intermediate slow PSK or QPSK based scheme that carries its own timing and sync.   FEC is something that could come later, we first of all want a simple PSK decoder scheme that search over a modest span in frequency - say 0.2Hz and with unknown timing .   I suggest differential BPSK as a stat, where the data depends on teh phase change from one symbol to the next.   That removes the need for absolute clock recovery, and also, provided tuning error is appreciably lesss than symbol rate, even for carrier recovery.   Just compare one block of digitised data (of a symbol's length) witjh the previous one and look for a peak every so often to get the boundary .  Some framing will be needed in order to guarantee a few phase changes for alignment.

A block / timed scheme like WSJT would probably work best as it reduces the searching for sync.  It also makes the soundcard driving software easier as a fixed length block can be recorded to a .WAV file more easily than continuous real time data reading from the s-card.

Once the signalling and signal recovery is proven, then is the time to think about adding FEC but even a none error-corrected scheme ought to have a fair bit to offer in testing.

The only real downside to PSK is its spectrum is you switch rapidly.   But its no worse than on-off keying, and if the signal is being generated by upconverting from a soundcard phase ramping could perhaps be used to reduce sidebands


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