How it works
Next
Previous

General

The difficult part of any digital mode software is the decoding, and to a lesser extend the coding, of the audio signal. Luckily the WSJT-X suite contains 2 executables that perform coding and decoding for the JT9 mode. But the decoding executable can only decode JT9(-1), not JT9-2, JT9-5 or JT9-10. Rather than adapting the existing decoding software for JT9-2 JT9-5 or JT9-10 the unmodified decoder is used and the incoming audio signal is modified before it is send to the decoding software.

This modification is done by resampling ("speeding up") the incoming audio signal by a facor of 2.22 (for JT9-2), 5.93 (for JT9-5) and 12 for JT9-10. That way they look like JT9(-1) signals to the decoder.
SlowJT9 does the resampling and provides a user interface, while the decoding is still be done by the original JT9 decoder.

At first glance it might seem foolish to convert JT9-2, JT9-5 or JT9-10 signals back to JT9(-1), but this conversion process will also reduce the noise level and thus improve the S/N.

Although this way of working simplifies the software a lot it also comes with a restriction:
Speeding up the audio by a factor X results in a identical increase of the audio frequencies. This means that an original 600 Hz audio tone will be at 1333 Hz for JT9-2, 3556 Hz for JT9-5 and 7200 HZ for JT9-10. As that maximum audio frequency that can be handled by the JT9 decoder is 5000 Hz this means that the maximum usable audio frequency is 2250 Hz for JT9-2, 843 Hz for JT9-5 and 416 Hz for JT9-10.
But SlowJT9 handles all these frequency conversions, so apart from the fact that the maximum audio frequency is limited the users don't have to take care of this (and won't even notice it).


Resampling

The parameters of all JT9 submodes were described in the WSJT-X User’s Guide version 1.0 (May 3, 2013):

Parameters of five JT9 sub-modes are summarized in the following table, along with approximate S/N thresholds measured by simulation on an AWGN channel. Numbers following "JT9-" in the sub-mode names specify TRperiod in minutes.
SubmodenspsSymbol Duration (s)Tone Spacing (Hz)Signal Bandwidth (Hz)S/N Threshold* (dB)QSO Time (minutes)
JT9-169120.581.73615.6-276
JT9-2153601.280.7817.0-3012
JT9-5409603.410.2932.6-3430
JT9-10829446.910.1451.3-3760
JT9-3025200021.000.0480.4-42180
* Noise power measured in 2500 Hz bandwidth.


As can be seen the nsps (number of samples per symbol), signal bandwidth, 1 / symbol duration and 1 / tone spacing ratios are all the same between the submodes:

That makes that all submodes can be converted to JT9-1 just by resamling the incoming audio signal by the given ratio.
For an integer ratio resampling can be very simple, for a ratio N each output sample is calculated by taking the average of N input samples. For a ratio of 4 this would be:

 

 

For non integer ratio the resampling becomes a bit more complicated. For JT9-2 to JT9-1 resampling the ratio is 15360/6912 = 20/9. That means that for every 20 input samples 9 output sample must be generated, or one output sample for each 2.222222.. input samples.
A straightfoward way to do so it to take weighted values of the input samples:

 

 

Although weighted value resampling works fine, SlowJT9 uses a better (but more complicated) way named windowed sinc interpolation to perform the resampling. Tests have shown that this method gives a slightly better result, just about 0.7 dB but for weak signals every (part of a) dB counts!


Multiple decoding

It all started with a mail from David, G0MRF, (17 Januari 2019):

Last night was very good for propagation and TA activity on 630m. It was one of those rare nights where signals were at a reasonable to good level, but unlike the previous several days, if not weeks, QSB was remarkably slow with only a few dB between peaks and troughs. There was a period between 02.00 and 04.00 with no decodes here, but between 06:25 and 07:49 I decoded 19 transmissions from K9KFR in EN77, most of which were CQs I was pleased to work Glenn VE9GJ on JT9 shortly after he made his first TA QSO with Jan LA3EQ. Interestingly Rik's SlowJT9 which was running in parallel, managed to decode a couple of more transmissions than WSJT-X.

As I use the JT9 decoder from the WSJT-X suite the performance of SlowJT9 and WSJT-X should be identical. The only difference between both could be a small timing difference that made SlowJT9 to decode some extra transmissions (pure luck, it could have been the other way around as well).
But maybe the performance of SlowJT9 could be improved by running the recorded audio several times through the decoder with each time a small time shift induced in the audio and then taking a "best off" all decoded signals?
The fastest way to find out wether this was a good or bad idea was to do some computer simulation where a JT9(-1) signal was generated at different SNR levels (-24dB to -29dB in 0.2 dB steps) and fed to the JT9 decoder. Next this signal was shifted in 0.2 second steps (up to +/- 1 second) and decoded again.
The graph below shows the results:

 

 


These results convinced me that it was worth a try! And the estimated QSO duration versus SNR graph is even more impressing:

 

 

UDP broadcast

UDP broadcast allows an application to send messages to all computers in a LAN. In case of SlowJT9 all decoded messages will be broadcasted.
UDP broadcast is done in plain text, using the | (vertical bar, ASCII value 124) symbol as field delimiter.
There are 4 types of UDP broadcast:


Front End Mixer

Using the Front End Mixer the incoming (RX) audio signal can be downconverted. This allows reception of JT9 signals at frequencies above the physical frequency limit due to the resampling and decoding process (4980 Hz for JT9-1, 2240 Hz for JT9-2, 840 Hz for JT9-5 and 415 Hz for JT9-10).

In order to get a decent rejection of the carrier, unwanted sideband and mirror frequency a phasing method mixer is used: