1. RTTY is a well-defined protocol; the result of any modifications to this protocol would not be RTTY.
2. Significant work has been done to improve RTTY decoding; see https://www.rttycontesting.com/downloads/2tone/ (David G3YYD) http://www.dxatlas.com/Gritty/ (Alex VE3NEA) Some digital mode applications can simultaneously display the results of several different RTTY decoders. 3. Each candidate development task has an "opportunity cost". The time spent extending WSJT-X to support RTTY is time that can't be spent improving WSJT-X in other dimensions. The WSJT-X developers are in a unique position to improve their product; there are many other developers who can further improve RTTY applications. David and Alex continue to improved their applications, and MMTTY is open source. Thus I strongly recommend that the WSJT-X team continue to apply that all-too-rare skill among software developers: focus. 73, Dave, AA6YQ I'm not so sure it would be that easy. All of the WSJT-X modes require some pretty rigid rules, not the least of which is fixed time frames closely locked to the same reference. They also require some pretty narrowly constrained message formats. I really doubt that very many current RTTY users would be willing to give up their current flexibility. If they were, they'd be a whole lot better off just to migrate to FT8 or FT4. Besides, the RTTY protocol by definition has some rather severe limitations, only two tones being one of them. 73, Dave AB7E On 1/14/2020 5:21 PM, Frank Kirschner wrote: Dwayne, That's what I suggested some time ago. Not only would it put all the digital modes I use together in one program, but it would provide an opportunity to implement a really good RTTY detection algorithm. Some of the current programs require a very high S/N, and with the signal processing know-how of the originators of WSJT-X, I'm sure that could be improved upon. 73, Frank KF6E On Tue, Jan 14, 2020 at 2:28 PM Dwayne Sinclair <nna...@gmail.com> wrote: Hey all, My background is IT infrastructure with some code development and I although I have been active in the amateur radio community for less than a year, given my software, IT infrastructure background, and electronics background I have been assisting my local amateur radio community in all aspects of computer interfacing to radios. First off, I am really impressed with what has been accomplished with WSJT-X and I am an avid user of all digital protocols including FT8, FT8 WSPR and others. I recently attended a DX Club meeting and got to see first hand the resentment towards FT8 in the context of DXCC awards. I never got to speak in defense of FT8 but what I do believe is there is a basic misunderstanding on the fact that WSJT-X’s success is much about the interface that WSJT-X provides to managing QSO’s. “Ease of digital use” is completely missed on much of our older amateur radio community yet the same operators have fully embraced RTTY as a digital protocol. I would like to propose adding RTTY to WSJT-X for two reasons 1. As a means to reframe the DXCC discussion away from FT8 itself to “it’s just a UI for managing QSO’s”, and 2. I believe WSJT-X would be a great tool for RTTY. From an implementation perspective it may be possible to run interval and interval less with RTTY with the WSJT-X UI. Regards Dwayne Sinclair NA6US Redondo Beach, CA _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
