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
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|