Hi, Bill, Thanks for your reply.
I wasn't suggesting a change to the standard for RTTY, which, of course, would be impossible at this point. I was pointing out that the software I have used to decode RTTY is nowhere close to the theoretical limit, or even the hardware discriminator I built years ago. DM780 and MMTTY, the two programs I remember using, require very high signal to noise ratios to provide even moderately good decoding. Do you have a recommendation on software that might perform better than what I am using? I first used RTTY in the late 1960s, when I had my home-brew TU and a Kleinschmidt teleprinter, so I'm familiar with the electro-mechanical technology for which Baudot code was designed. I designed a weather collection network for Thailand in the early 1970s that used mechanical teleprinters and prepared tape messages. It was a bit of a kluge, but it worked for years. 73, Frank KF6E On Thu, Jan 3, 2019 at 10:52 AM Bill Somerville <[email protected]> wrote: > On 03/01/2019 15:33, Frank Kirschner wrote: > > Many years ago, I had a home-brew RTTY TU. It had two 88 mH torroids > > in the tuned circuits and a differential amplifier as a detector. > > Occasionally, the received signal would fade below the noise, but the > > Kleinschmidt teleprinter would keep printing the decoded text. I have > > tried several current software packages for decoding RTTY signals, and > > all of them require quite strong signals to decode at all, and very > > strong signals to provide 100% print. > > > > I was wondering if the decoding method used in WSJT-X for FT8 could be > > ported to a RTTY decoder. I realize that FT8 has a lower symbol rate, > > which provides more time to integrate, and incorporates redundancy, > > which improves accuracy. But the theoretical lower limit for decoding > > RTTY is something like -5 dB S/N, and the current programs are nowhere > > near that. > > > > If RTTY facilities could be integrated with WSJT-X, not only would the > > decoding be better, but the log scanning functions of WSJT-X and > > JTAlert would be better, significantly improving contest operation. > > > > I confess I haven't looked at the decoding techniques used by RTTY > > software, but I suspect, based on performance, that it could be improved. > > > > 73, > > Frank > > KF6E > > > Hi Frank, > > this is well covered ground, some existing Baudot decoders have very > good performance with built in weak and fading signal models to optimize > them. > > The techniques used to decode FT8 are based around a block message > format that includes parity bits and checksums for advanced forward > error detection and correction, Baudot is a character based stream code > with no forward error correction capability. RTTY was designed for an > era where automation was mechanical and quite limited, just having a > code that could be used to modulate a transmitter and be printed by a > receiver was about the sum of the technical design. RTTY's *only* > similarity with FT8 is that it is a frequency shift keyed constant > amplitude signal. Even the simplest addition of a single parity bit to > detect, but not correct, single bit errors would need a fundamental > non-backwards compatible change to the Baudot code. > > 73 > Bill > G4WJS. > > > > _______________________________________________ > wsjt-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wsjt-devel >
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
