On Fri, Jan 17, 2020 at 3:01 PM David Gilbert <[email protected]> wrote:
> > I realize that you aren't proposing "changing RTTY", but that is > essentially what you would have to do if you wanted to make use of the > majority of FTx's better sensitivity ... so clearly you still do not > understand. > I do understand that most of the improvement in sensitivity using FT modes comes from other sources, like longer integration time, redundancy, error correction, multiple decoding passes, etc. I would never expect RTTY to approach the low signal levels that FT modes are capable of. But there is a wide range of capabilities in the RTTY programs that are currently available, so it is clear that some have more robustness in the presence of noise than others. And none of the programs I have tried achieve the performance that my old hardware T/U exhibited in 1970. So I'm sure there is still room for improvement. I'm not sure what your degree is in, but I'm pretty sure it wasn't signal > processing. > Ph. D. in EE from Ohio State, with minors in digital signal processing and communications theory. I have taught both at the graduate and undergraduate level. I took a course in error correction codes from Dick Hamming, after whom hamming codes are named. > > The bulk of WSJT-X's better performance compared to RTTY comes from > several things ... among them the requirement to be locked to preset time > windows, the use of 8 (or 4) tones instead of 2 tones, the use of forward > error correction, and multi-pass decoding. Sophisticated filter algorithms > have been around for decades and do not provide the bulk of FTx's better > performance. > > My son (degree in both math and computer science) actually writes > extremely sophisticated signal processing software for a state-of-the-art > quasi-military company and I asked him to look at the WSJT-X source code > (which is readily available under GNU). He was impressed with K1JT's > implementation of modern decoding systems like the Costas arrays (less so > with the heavy use of Fortran coding), but the really clever schemes are > not generally applicable to just any set of time-variable tones ... > particularly if there are only two of them. > I didn't say they were. But current RTTY programs can be improved considerably. > > K1JT does other things that are clever (albeit also known in the signal > processing industry) such as recreating the signals decoded in a first > pass, subtracting them from the recorded data, and doing a second pass > decode ... as well as what K1JT calls a prior decoding, which essentially > means don't spend resources decoding anything that you already know, like > the callsign of the other station by the time you get to message #3. > Again, these aren't applicable to standard RTTY. > > And if you still aren't convinced, here is a direct quote from the WSJT-X > manual: > > I've read the manual. > Standard RTTY doesn't pre-compress the data, does not use FEC, and none of > the information in the quote above is compatible with standard RTTY. > So you believe that all the RTTY programs currently available are at the theoretical maximum in robustness in the presence of noise? > With that, I'm done arguing with you. > Well, you never were really arguing with me. You started with strawman argument, and then went grasping for straws. > Believe what you want, but it isn't supported by reality. > The reality is that there is a wide range of performance among the currently available RTTY programs, and even the best ones can be improved. > Dave AB7E > > 73, Frank KF6E
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
