Message-ID: <004101c244a2$6b6b73b0$687a37c0@w2ksn>
From: "Stewart Nelson" <sn@scgroup.com>
To: rsgb_lf_group@blacksheep.org
References: <76.20a5d68e.2a8954d1@aol.com> <5.1.0.14.0.20020813153546.00aa3f28@gemini.herts.ac.uk>
Subject: LF: Re: Re: Limiter in Jason reception
Date: Thu, 15 Aug 2002 14:26:28 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Sender: <majordom@post.thorcom.com>

Hi Jim and all,

> BTW, when watching the decoder in action, "G4JNT" first decoded correctly,
> then the decoder retrospectively blanked out the "G" - On the whole, I
> think it would be useful if the decoder prints some character even if it
> "knows" the character is wrong - perhaps a non- alphanumeric character like
> a question mark or just a blank. That way, the operator would know how many
> characters had been missed - although it would mean more garbage on the
screen.

The decoder does print a lower case 'x' for invalid characters.  Your case is
a different bug -- the decoder mistakenly thought that the symbol phase had
changed, and there was no place for a character with the new phase.

Unfortunately, one can't simply ignore such shifts; we need to accommodate
restarts at the Tx end, retuning of the Rx, Tx started after Rx, etc.
So the decoder needs to compare, using a suitable metric, the quality of the
various choices, and output the most robust.  This will still sometimes be
wrong, but it should be a significant improvement.  I'll try to address this
in the next version.

73,

Stewart