W7AY wrote, in part: /"...//(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 :-)."/
This caught my attention right off the bat! I know there are "CW message
testers" which provide character & element counts, so where do I find
this aide for RTTY? I might have to get a vanity call!
And thanks for the very thorough write-up Chen... it pushed my knowledge
forward regarding what can be done to enhance the RTTY experience. You
convinced me to pull the Power Mac G4 that's been sitting on the shelf
and consider firing it up! I need to find a keyboard first.
73 de Bob - KØRC in MN
------------------------------------------------------------------------
On 2/1/2012 3:41 PM, Kok Chen wrote:
> 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
>
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|