[RTTY] Multiple Decoders

[Kok Chen]

On Feb 1, 2012, at 12:28 PM, Jeff Blaine wrote:

> Can you then expand a bit on the sync scheme comment?

Urgh, I shouldn't try to disclose something on software I have not yet released publicly.  But here goes:

My investigations came about after I was looking into the start-stop mechanism for character sync that I described in "What Got Us Here?" section of

http://w7ay.net/site/Technical/RTTY%20Demodulators/index.html

If you dig back into old RTTY Bulletins, you will find allusions to the fact that an error in the start/stop bits can cause error rates to triple.  I kinda explained this error rate explosion as a "cycle slippage" problem (when trying to recover sync again) in Don's "Getting Started on RTTY -- Technical Discussions of Diddles."

http://www.aa5au.com/gettingstarted/rtty_diddles_technical.htm

I have seen cycle slippage causing 5 extra character errors from a single start-stop error.  Sometimes it is as low as a single character error -- it all depends on what exactly is being received (here is where you can choose a better RTTY call sign, versus the usual way of choosing a callsign that is shortest in Morse code :-).

If you have diddles turned on, you can consider RTTY to be a synchronous stream.  Further, if you make an assumption of how many stop bits there are, you can use past and future bits to determine the character sync.  I believe what RITTY calls "Digital Flywheel" makes use of past bits (I have not seen the code, so I don't know for sure).

The disadvantage is that the synchronous method fails completely if you didn't guess the number of stop bits correctly (granted that modern computers are so fast you can try all cases like 1, 1.5 and 2 stop bits in parallel, instead of making the op set the correct number of stop bits).  

It also fails when the other end does not use diddles, or when the other end uses stuttering diddles. Stuttered diddles can be caused by an Elecraft K3 when the op is using a Morse paddle to enter characters.

The RITTY "Digital Flywheel" not only helps in the case of a noise corrupted start or stop bit, but it also helps in the QSB case.  

When I looked into it, you can in fact do much better by using not just the "past" bits of data, but also the "future" bits (more on this below).

In fact, being able to maintain good character sync can drop the character error rate by a factor of 10 or sometimes more.  I.e., if you take a look at fading and flutter charts in VE3NEA's page (http://www.dxatlas.com/RttyCompare/), the new curves start from the same point when SNR is very poor (100% CER) but then dives deeply so that by the time the modems showed in VE3NEA's chart are at 10% error rate, the pseudo synchronous scheme was giving 1% error.

OK, how do you look for "future" bits unless you are a fortune teller?  By delaying all the bits of course.  In my experiments, I actually store delayed waveforms (:-) from the Mark and Space filters, since memory is so cheap nowadays.

The problem with adding this delay -- latency.  The characters will lag the real time input by 5 or more characters (possibly 1 or more seconds).

The solution is an adaptive scheme.  If we had been in sync in the past and the latest character maintains sync, you print it immediately -- this will happen 99% of the time.  If for some reason you loose sync (either from QSB or from a noise hit), you delay the output until you gather more data from the bits that come afterwords.

If after a sufficient delay, you still don't find a global pattern (i.e., when the other end does not send a diddle, or they are using a paddled K3), you revert back to looking for individual start and stop bits.  With incorrect diddles, you simply don't take advantage of what I call "pseudo sync."  

I do not believe RITTY's "Digital Flywheel" can handle the malformed or non-diddled cases, I believe that you need to turn the flywheel off manually.

So, instead of looking at just one start bit and one stop bit, you look at ten start bits and ten stop bits, for example.  If the majority of the start and stop bits are correct, you assume that the current character is properly timed even if its own start and stop bits are bad. 

If you include enough past and future characters, you can pretty much assume that the start and stop bits do not contribute any error (remember that each doubling of bits will improve the SNR for those bit by 3 dB).  Just look at what an SNR improvement of 9 dB does to the error rate in VE3NEA's charts.

Not only does the "cycle slippage" problem go away, the character error rate per se also drops.  I.e., if the probability of a bit error is "p", a 7 bit pattern will be correct with the probability 1- p^7.  With the pseudo sync method, this number is 1-p^5+epsilon, where epsilon is very small, since we are not even looking at the individual start and stop bits.

(For FORTRAN readers, use ** instead of the caret (^) in the previous paragraph.)

There is a further problem that also has to be taken care of when you are looking at a bit pattern that has over 50 bits -- the accuracy of bit clocks, either  caused by AFSK from a computer with poor sound card sampling rate accuracy, or from FSK digital interfaces that do not do 45.45 baud exactly (imagine what 45.0 baud will do after 50 bits).  This is not hard to solve as long as you know ahead of time that it will happen.

With a good pseudo sync scheme and a good Nyquist filter for the Mark and Space channels, you will arrive at RTTY nirvana.

73
Chen, W7AY