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'm not sure what your degree is in, but I'm pretty sure it
wasn't signal processing.
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.
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:
"
*****************************************************************
To be useful on channels with low signal-to-noise ratio, this kind of
lossless message compression requires use of a strong forward error
correcting (FEC) code. Different codes are used for each mode. Accurate
synchronization of time and frequency is required between transmitting
and receiving stations. As an aid to the decoders, each protocol
includes a “sync vector” of known symbols interspersed with the
information-carrying symbols. Generated waveforms for all of the
/WSJT-X/ modes have continuous phase and constant envelope.
17.2.1. FT4
Forward error correction (FEC) in FT4 uses a low-density parity check
(LDPC) code with 77 information bits, a 14-bit cyclic redundancy check
(CRC), and 83 parity bits making a 174-bit codeword. It is thus called
an LDPC (174,91) code. Synchronization uses four 4×4 Costas arrays, and
ramp-up and ramp-down symbols are inserted at the start and end of each
transmission. Modulation is 4-tone frequency-shift keying (4-GFSK) with
Gaussian smoothing of frequency transitions. The keying rate is
12000/576 = 20.8333 baud. Each transmitted symbol conveys two bits, so
the total number of channel symbols is 174/2 + 16 + 2 = 105. The total
bandwidth is 4 × 20.8333 = 83.3 Hz.
17.2.2. FT8
FT8 uses the same LDPC (174,91) code as FT4. Modulation is 8-tone
frequency-shift keying (8-GFSK) at 12000/1920 = 6.25 baud.
Synchronization uses 7×7 Costas arrays at the beginning, middle, and end
of each transmission. Transmitted symbols carry three bits, so the total
number of channel symbols is 174/3 + 21 = 79. The total occupied
bandwidth is 8 × 6.25 = 50 Hz.
"
*********************************************************************
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.
With that, I'm done arguing with you. Believe what you want, but it
isn't supported by reality.
Dave AB7E
On 1/17/2020 9:15 AM, Frank Kirschner wrote:
On Wed, Jan 15, 2020 at 1:44 PM David Gilbert
<xda...@cis-broadband.com <mailto:xda...@cis-broadband.com>> wrote:
You're assuming that the algorithms used in WSJT-X would be
adaptable to RTTY to give better performance than what is already
out there.
It is certainly true that the algorithms used in WSLT-X for
discriminating frequencies could be adapted for RTTY. Why wouldn't
they? All they do is discriminate what frequency is being received.
I'm not sure that the newest RTTY programs don't already use this same
algorithm, but the noise performance of the RTTY programs I've tried
so far has been pretty poor, and improving the algorithm used would
ameliorate that.
I don't think there is any evidence of that being the case,
given the very rigid constraints that every single WSJT-X mode
requires.
That has nothing to do with it. At some point in the flow of the both
RTTY programs and WSJT-X, a decision is made: was it this frequency or
that frequency? There's an algorithm that does this. I suspect that
the writers of WSJT-X have used the best algorithm that would run on
computers available, This algorithm, used in a RTTY program, would
improve the noise performance of decoding. The integration time
available for RTTY is much less than modes like FT8, and FT8 uses
redundancies and limited code words, but they both need to
discriminate between frequencies. The work that WSJT-X does over and
above frequency discriminating has nothing to do with RTTY, and it
wouldn't be in a RTTY program.
The appeal of RTTY for almost everyone (compared to FT8 or FT4) is
its free form nature. Just go read the current dialog on the
CQ-Contesting reflector to see what I mean.
PSK-31 is much better for free-form communications than RTTY. It has
better noise performance and can copy through fades better. I believe
most people who operate in RTTY contests don't use a free-form mode
anyway. They have the exchange in macros, including the QSO counter,
and they never touch the keyboard. If there are many stations on,
retyping the same info for every QSO would be a waste of valuable
operating time. All the RTTY programs I've tried have macros and some
sort of contesting mode.
If you try to turn RTTY into a 2-tone version of FT8 neither user
base will ever use it because it doesn't have the advantages of
either mode.
I don't know why people keep saying that. I never suggested a change
to RTTY. All I suggested was that improving the software discriminator
in a RTTY program might produce a useful improvement in noise
performance. And if somebody wrote such a program, it would be useful
to integrate it to some extent with WSJT-X to make switching modes easier.
Secondly, WSJT-X is simply a very bad contest user interface. It
was designed for weak signal DXing and it does a very good job for
that, but it is terrible for contesting. Again, check out the
CW-Contesting reflector (you can just read the archives if you
aren't subscribed) to see more comments on that point ... most of
which have been from me.
No one suggested using the WSJT-X UI for a RTTY program. The
discriminator and the UI are independent of one another. Someone could
create a program with the same discriminator algorithm that WSJT-X
uses, and give it a very contest-ready UI. The pace of FT8 contesting
is much slower than that of CW or RTTY. It's very leisurely, and
optimizing the UI for contesting isn't necessary. WSJT-X does have a
number of user conveniences, like automatic logging, so clearly some
thought has been put into making it a practical program, as opposed to
just a test program for a lab.
I really don't think you understand what you keep proposing here,
I assure you, I do. I have the academic and teaching credentials that
show I do. But that's not the issue here.
I suspect you don't understand what I'm proposing, based on your
comment above. I'm not proposing a change to RTTY, as you suggested,
but an improvement in an algorithm in RTTY receiving programs.
Let me restate in clearer terms: It would be nice if someone (not
necessarily the WSJT-X developers - there are other programmers in the
world, so it wouldn't take time away from the WSJT development) wrote
a RTTY program that played well with WSJT-X, SliceMaster, and JTAlert,
and used the best frequency discrimination algorithm currently
available. That would facilitate switching modes, provide very useful
"needed" and "B4" alerts, and improve noise performance over current
RTTY programs. Since FT8 and RTTY are often used in the same contests,
switching back and forth easily would be useful feature. I'm NOT
proposing any changes to RTTY.
but it doesn't really matter because there is no way Joe Taylor is
going to mess with it since I'm sure he does.
Joe Taylor is a very good scientist and programmer, but he's not the
only programmer in the world. Other people might be interested in this.
There is rumored to be a new version of CW Skimmer in the works, one
that will integrate well with Flex Radio's SSDR. It will be callable
by SliceMaster, the same program that calls WSJT-X on many hams'
set-ups. So other people can still provide the ham community with
useful software. Clean integration of programs is becoming a more
significant goal as more and more functions are computerized. I don't
see why this shouldn't be the case with RTTY.
Dave AB7E
73,
Frank
KF6E
_______________________________________________
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
