RTTY
[Top] [All Lists]

Re: [RTTY] TinyFSK modem for 45 and 75 baud

To: RTTY Reflector <rtty@contesting.com>
Subject: Re: [RTTY] TinyFSK modem for 45 and 75 baud
From: Kok Chen <chen@mac.com>
Date: Fri, 11 Oct 2013 11:57:30 -0700
List-post: <rtty@contesting.com">mailto:rtty@contesting.com>
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

<Prev in Thread] Current Thread [Next in Thread>