On Oct 11, 2013, at 5:57 AM, Bill Turner wrote:
> May I ask how this timing problem manifests itself
> over the air? Poor weak signal reception? Or what?
I will let others desribe the features that Andy's implementation provides.
Let me provide some "color" to why it is important.
Two things that Andy addressed are the non-constant (jittery) bit rates, and
the jittery stop bit.
If the bit period is not constant, in the extreme case, the signal cannot
copied even when the signal has good SNR -- for a constant amount of bit
jitter, this becomes worse as baud rate is increased. This is especially
noticeable with 75 baud and bit-banging methods such as EXTFSK.
Stop bit period varying (which is the next common problem) is not a big problem
today, unless the receiving end is using is using RITTY and the numerical
flywheel. Not only do you lose the advantage of the "flywheel" (which reduces
the character framing errors), a non-constant stop bit period makes
psedo-synchronous methods like the numerical flywheel perform worse than
standard start-stop asynchronous reception. But the stop bit being not
precisely 1, 1,5 or 2 also causes the ISI that affects all other bits.
First, let me drill further in on the bit period problem...
At 45.45 baud, the problem is usually not outright non-copy, but degraded copy.
Filters in 2Tone and fldigi today take advantage of the Nyquist property to
reduce intersymbol interference (ISI). (Note that RITTY and cocoaModem use
the Matched Filter, which are already Nyquist, by definition.).
One of the things about Nyquist filters is that there is only zero ISI when the
baud rate is precise. Take a look at the impulse response of the Raised Cosine
filter. These filters becomes worse than a wide non-Nyquist filter when the
bit period is not constant -- especially so when the bit period is shorter than
what the filter is designed for (22ms for 45.45 bud RTTY).
Raised Cosine filters are not new. They have been mentioned even in the RTTY
Bulletins in the mid-1960s, but they simply could not be implemented with
analog circuits. Victor Poor [designer of the Frederick Electronics 1280] had
suggested a 3 pole Butterworth, for example to roughly approximate the Raised
Cosine.
When you use an FIR filter today in a software modem, it is a matter of
properly designing the coefficients of the filter. It does not take any more
CPU cycles than using a crummy filter.
The insidious part of bad baud rate is that the sender (transmitter) does not
even realize it is happening. His signal is just causing more error hits at
the other end, and the other end probably think that the copy is degraded
because of propagation.
BTW, some people think that a wrong baud rate is not a problem until the clock
error is off by 1/2 a bit after 6 bits -- but that is not the problem. The
problem is ISI, which hits you well before the 1/2 bit error.
Next, we can look at the harm from stretched stop bits:
The main disavantage today is that the stretched stop bits will cause a contest
exchange to take longer (no big deal for DX guys unless you are the
DXpeditioner :-) -- depending on the latency to get characters into the UART
(especially if the UART does not include a usable FIFO), this can add a couple
of milliseconds to every character, so perhaps tens of milliseconds to every
contest exchange.
Today, everyone who uses 2Tone has a tool to see how much the stop bit is
stretched on a received signal. 2Tone displays the stop bit length. Before
2Tone, only modem developers were measuring this parameter.
As modem developers finally are achieving close to theoretical error rates from
better filters and ATC (we are pretty much within a fraction of a dB now from
the theoretical limit for AWGN), one area that they can be working next are
pseudo synchronous methods to recover the approximate 3x error rate when a
start/stop synch is lost. It is the next "low hanging fruit."
If you listen to RTTY enough, you may have noticed that errors often occur in
pairs or triplets (and less often, 4 or 5 character sequences) -- this can be
caused by a deep QSB or a noise pulse that is about half a second long. More
often, it is happening because the stop bit to start bit transition suffers an
error hit.
(BTW, bit errors in PSK31 always occurs in pairs -- but for a different reason,
and often does not straddle across two characters.)
After you lose stop-start frame sync in RTTY, the decoder has to now find the
next true stop-start bit pair. Since there are other data patterns that look
like a stop-start bit pair, the decoder could mistake frames, and will need to
go through some cycle-slippage until the proper frame sync is again found.
Probabilistically, it takes about 3 Baudot characters to recover from a framing
error. So a single bit error (located at the stop or start bit) can cause 3
characters worth of errors, instead of a single character error when the error
hit is on a data bit.
Beard and Wheeldon of Marconi Company measured it in practice (reported in a
paper in June 1960) and found it to be slightly worse than 3 characters on
average.
When I mentioned in my "RTTY Demodulators" article that I was missing the Beard
and Wheeldon paper, two people sent me copies of it. One was Jim (W6JVE,
ex-WA9IBB) who was the person who mentioned the Marconi paper in the August
1963 issue of the RTTY Bulletin.
The other person who sent me a copy of the Beard and Wheeldon was David G3YYD
who had a scanned copy among his files. So, you can be sure that David, the
author of 2Tone, is well aware of this particular drawback of asynchronous
(stop-start) RTTY, and you can expect 2Tone to address this to get better RTTY
copy. When that happens, it benefits you to send with good stop bits, since it
means that someone at the other end that uses 2Tone will copy your signal with
fewer errors.
73
Chen, W7AY
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|