What would that be? FT8/FT4 uses a better detection scheme than RTTY
precisely because of the constraints that FT8/FT4 require. Those
constraints are what allow the better decoding ... there is no "magic"
involved here. If you lock the signal to predetermined time windows,
use 8 tones instead of 2, and constrain the message to a narrow protocol
you can use more effective decoding than you could otherwise. If you
don't do those things, you're pretty much limited to various
sophisticated two tone filter techniques just like the current RTTY
applications use.
Dave AB7E
On 1/14/2020 6:18 PM, Frank Kirschner wrote:
I'm not suggesting changing the RTTY FSK standard. I'm suggesting a
better detection scheme for the existing RTTY standard.
73,
Frank
KF6E
On Tue, Jan 14, 2020 at 7:54 PM David Gilbert
<xda...@cis-broadband.com <mailto:xda...@cis-broadband.com>> wrote:
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
<mailto: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 <mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
