[pskmail] jPskmail 2 (THOR Modem)

From: John Douyere <vk2eta@xxxxxxxxx>
To: pskmail@xxxxxxxxxxxxx
Date: Fri, 2 Dec 2011 18:22:42 +1100
Rein,

I fixed the Thor TX modem. I found it easier after debugging for a while to
copy the working Android version over as it was already working on that
platform.

I also fixed a bug in the THOR modems that prevented the end of sequence
to fully benefit from the Viterbi encoding as there was a lack of bits sent
to the interleaver to flush it at the end of a frame.

This is also in Fldigi and can be seen by looking at the end of sequence in
a noisy environment. It should always finish by a <Line-Feed, EOT,
Line-Feed> sequence but it doesn't even if the previous characters were
decoded properly. Fldigi gets by due to the extra characters sent at the
end of the frame, in some cases it is not enough: if the first bits of the
encoder get damaged towards the end of a frame it would not decode properly.

I have also made some changes (originally in the Android version but now in
both) after numerous tests on the RSID decoder: I re-balanced the risks of
decoding the wrong mode versus not decoding it at all. In our application
the worst case is if we regularly interpret another signal (i.e. MFSK or
THOR) as a valid RSID sequence thereby changing the mode mid-frame and
loosing the rest of the transmission.

The almost as bad situation is when we do not decode the RSID at all, as
this results in a missed communication (both on the server side at connect
or unproto frame receive or at mode change on the client side).

Also it was clear that in the current settings of Fldigi we would not
decode RSIDs at 100% with a number of misses even at good s/n ratios.

Furthermore the modes like THOR8 and even THOR11 would be more sensitive
than RSID under white noise conditions and that by at least 2 or 3 dB which
is quite significant.

I reviewed the Hamming distance criteria of RSID and came to the conclusion
that it is way too much on the safe side with only one error in the whole
sequence allowed for.

I therefore increased the allowed distance to 5 and sent long frames of
data in various modes for checking. I have not been able to get a false
positive so far in both Java implementations, but more field testing is
required.

The only false positive I could get in Fldigi was that DominoEX 5 would be
decoded and then THOR22 strait after, with the first one being a false
positive, immediately corrected by the proper mode. In Fldigi I can get
down to -15dB in white noise before I do not get any decode compared to
-13dB before. So it seems that we can decrease the allowed errors to 4 in
Fldigi.

In jPskmail and AndPskmail I can now get down to -13dB and still decode. I
get no decode at -14dB (THOR22 as reference mode).

So I propose, since our list of modes is much smaller to leave the maximum
errors at 5 maximum in the java implementations and see what we get from
field tests.

But all in all it is a significant improvement in the decoding of RSIDs by
the java modems.

I need to port this back to Fldigi for the server side (enabled only when
in Pskmail server mode).

73, John
[pskmail] jPskmail 2 (THOR Modem)

Other related posts:
