[RTTY] TinyFSK modem for 45 and 75 baud

[Kok Chen]

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