MIME-Version: 1.0
In-Reply-To: <165aeea613a-1ec0-427@webjasstg-vab55.srv.aolmail.net>
References: <5B911389.9080807@posteo.de> <165aeea613a-1ec0-427@webjasstg-vab55.srv.aolmail.net>
From: Andy Talbot <andy.g4jnt@gmail.com>
Date: Thu, 6 Sep 2018 14:21:25 +0100
Message-ID: <CAA8k23Qs9aRiSuKoXaEpSENOVn8wLJZav9yNiggx78Zega3yag@mail.gmail.com>
To: LineOne <rsgb_lf_group@blacksheep.org>,
        rsgb_lf_group <rsgb_lf_group@yahoogroups.co.uk>
Subject: Re: LF: Slow JT9 modes...
Content-Type: multipart/alternative; boundary="0000000000009ff9ee057533c470"
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org

--0000000000009ff9ee057533c470
Content-Type: text/plain; charset="UTF-8"

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


Andy
www.g4jnt.com

--0000000000009ff9ee057533c470
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">As good as JT9 is, in whatever speed-flavour, at LF it thr=
ows away one aspect of LF propagation that isn&#39;t not really availalble =
for HF, phase stability over longer periods, at least suited to a few chara=
cters.=C2=A0 =C2=A0JT9 is a purely power-based system with heavy FEC.<div><=
br></div><div>So while slower versions of JT9 would be good for LF in=C2=A0=
 the short term, they will not make the most of what propagation can offer.=
=C2=A0 NO one on the WSJT-X development team is interested in LF, so it&#39=
;s no good looking there.=C2=A0 =C2=A0 However, I&#39;m sure they&#39;d be =
amenable to someone else joining the team and adding an LF users perspectiv=
e and writing / developing the relevant submodes.=C2=A0 =C2=A0Or do it inde=
pendently using the open-source code.=C2=A0=C2=A0<br><div><br></div><div>EB=
naut carries phase signalling to the extreme, carrying no sync / timing inf=
o in the on-air symbols and being completely reliant on high stability freq=
uency sources and people accurately starting and stopping.=C2=A0 =C2=A0This=
 complex manual setting is, in my opinion its downfall;=C2=A0 high stabilit=
y sources are less of a problem these days as OCXOs are now so cheap and re=
adily availalble.</div><div><br></div><div>What we need is an intermediate =
slow PSK or QPSK based scheme that carries its own timing and sync.=C2=A0 =
=C2=A0FEC 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 .=C2=A0 =C2=A0I suggest differential BPSK as a sta=
t, where the data depends on teh phase change from one symbol to the next.=
=C2=A0 =C2=A0That removes the need for absolute clock recovery, and also, p=
rovided tuning error is appreciably lesss than symbol rate, even for carrie=
r recovery.=C2=A0 =C2=A0Just compare one block of digitised data (of a symb=
ol&#39;s length) witjh the previous one and look for a peak every so often =
to get the boundary .=C2=A0 Some framing will be needed in order to guarant=
ee a few phase changes for alignment.</div><div><br></div><div>A block / ti=
med scheme like WSJT would probably work best as it reduces the searching f=
or sync.=C2=A0 It also makes the soundcard driving software easier as a fix=
ed length block can be recorded to a .WAV file more easily than continuous =
real time data reading from the s-card.</div><div><br></div><div>Once the s=
ignalling and signal recovery is proven, then is the time to think about ad=
ding FEC but even a none error-corrected scheme ought to have a fair bit to=
 offer in testing.</div><div><br></div><div>The only real downside to PSK i=
s its spectrum is you switch rapidly.=C2=A0 =C2=A0But its no worse than on-=
off keying, and if the signal is being generated by upconverting from a sou=
ndcard phase ramping could perhaps be used to reduce sidebands</div><div><b=
r></div><div>=C2=A0<br><div><br></div><div><br><div class=3D"gmail_extra"><=
br clear=3D"all"><div><div class=3D"gmail_signature" data-smartmail=3D"gmai=
l_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><=
div><div dir=3D"ltr"><div><div dir=3D"ltr">Andy<div><span style=3D"font-siz=
e:12.8px"><a href=3D"http://www.g4jnt.com" target=3D"_blank">www.g4jnt.com<=
/a></span><br></div><div><br></div></div></div></div></div></div></div></di=
v></div></div></div></div>
<br><div class=3D"gmail_quote"><br></div></div></div></div></div></div>

--0000000000009ff9ee057533c470--