Yes like all engineering there are some tradeoffs to be made between "Cost"
and "Benefit".
Ideally 2Tone would do an early decode and then a while later would update
the earlier decode with an improved decode. However as Chen says I am
constrained by the display medium in this case N1MM Di window and imitating
the MMTTY interface.
As a result I have had to make a judgement on performance against delay
time. Within reason the longer the delay the lower the marginal signal
character error rate (CER) will be. However most signals in a contest are
not marginal so a long delay is not warranted. But some signals are so some
delay is warranted.
As Don AA5AU observes there is software/hardware with shorter delay times.
So what advantages do longer delay times bring?
The first is filtering more taps on the FIR filter results in longer delay
but more accurate and sharper filtering. However there is no point in filter
performance grossly exceeding the RF/IF/AF performance of an excellent
receiver. I have measured and tested this area and discussed filtering with
Chen over the years and my conclusion is 512 taps at a 1500 samples/second
is about right for the analytic filtering. The delay in this filter is
170.7mS, about one character time.
Second by buffering the post filter data it is possible to look forward in
time to see what is happening to the signal in the future as well as the
past. This improves the assessment of signal and noise amplitudes -
essential for the frequency selective fading decoder and used to improve
performance of the other decoder types.
The buffering also enables averaging of the stop and start bits which by
improving the signal to noise (SNR) for these bits makes loss of character
synchronisation unlikely as an error source. This is why it is so important
to have low stop bit time jitter on transmit (note well). If 2Tone detects
substantial stop bit timing jitter it will not average these bits with
subsequent increase in error rate due to loss of character synchronisation.
Delay here is 170.7mS, about one character time.
Third by making use of the delays above it is possible to process two
character times of signal for AFC purposes before using the data for
character decode. This means that AFC is looking on average one character
ahead of the decoder resulting in improved AFC lock times and accuracy. (The
AFC has its own analytic based decoder.)
Fourth in some propagation modes there is an additional delay as a post
detection low pass filter(LPF) is used. The bandwidth of this filter varies
with measured SNR to obtain the best character error rate(CER) at different
SNR. If the LPF was just set for best CER at low SNR then the high SNR CER
would not be very good due to the bandwidth being too narrow. At high SNR
wider bandwidth is used so that the CER keeps falling with improved SNR and
does not asymptote as it does with many decoders. Delay here is about a
quarter of a character (42.7mS).
There is another source of delay that is unavoidable and that is
de-serialisation. The worst case scenario is the middle of the last data bit
of a character is just inside the next buffer and results in an additional
170.7mS delay but it can also be just in the current buffer so 0mS
additional delay.
So now you can understand why there is delay in 2Tone. The ideal would be to
have an addressable display so that the characters would come out fast and
then be updated if a later result improved the decode. Even longer time
delays would enable the use of additional techniques to improve decode
performance on marginal signals, but they are not suitable for a
contest/pile up situation.
Having said all of the above, it generates a thought and that is to have
another decoder in 2Tone called Fast. This would not have the CER
performance of the existing decoders but would deliver characters to the
display with low latency. (You do have squelch turned off? As squelch stores
last 4 characters for release when it opens).
73 David G3YYD
-----Original Message-----
From: RTTY [mailto:rtty-bounces@contesting.com] On Behalf Of Kok Chen
Sent: 12 June 2014 04:27
To: RTTY Reflector
Cc: Ed Muns
Subject: Re: [RTTY] 2 tone vs MMTTY
On Jun 11, 2014, at 9:00 PM, Ed Muns wrote:
> OTOH, that part of the decoding algorithm is probably key to 2Tone's
> excellent copy of weak and other marginal signals.
The trade off between a "low-latency crummy decoder" and a "high-latency
better decoder" can be solved if you allow new GUI elements into your modem.
Run two demodulators. The low-latency one prints first. The high-latency
decoder then overprints over those characters when they become available
from the high latency decoder. This way, your eyes do not need to switch
its focus between two windows. Strong signals will print correctly right
away.
Variations on this theme include using two different color fonts that
produces a third color when the two decoders agree, etc.
I had discussed this technique before with G3YYD for making even longer
latency decoders tolerable (for example, ones that corrects bit clocks by
using "future" bits for pseudo-synchronous clocking). But David is hobbled
by the existing modem user interfaces.
73
Chen, W7AY
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|