In a post about JT modes, I promised to repost about a comparison between JTDX and WSJT-X.
I can confirm that JTDX performs better than WSJT-X in JT-65 mode. According to the JTDX developers, JT-9 is not different from WSJT-X. From what I have seen, there is indeed no difference between the two in JT-9 mode.
But with JT-65, JTDX is the winner. I have been using is for several weeks now and I would not revert to WSJT-X. For me, the most distinct advantages of JTDX are:
- Decoding in crowded situations
- Filter option
It has to be said, that with pushing the limits, you have to be cautious. So please read the remarks at the bottom of this article.
When there are overlapping signals, WSJT-X only decodes one or even fails. It is really incredible how JTDX manages to reveal weak signals that are covered by stronger signals with differences of over 15 dB. As I am writing a parser for the all.txt file, I will study the decodes for examples. But I have seen many examples of these decodes.
Here is a side by side screenshot, both programs decoding the same .wav file. It is just one example, illustrating the difference, but it represents the broader findings.
I recorded about 5 minutes on 5357 kHz on Jan. 2nd, 2017 through a web sdr (Twenthe). I was too lazy to go into the shack hi.
The screenshot of WSJT-X was pasted over that of JTDX. The differences are outlined. The DK7UV HB9FUR 73 was completely missed by WSJT-X and the two signals of DH8IAT and OZ6ABL were nearly zero beat (1660 and 1661 Hz) and both relatively strong. JTDX decoded both whilst WSJT-X missed them completely. It can definitely save a QSO.
Yesterday evening, I listened on 5290 for a while to see if I could read ZS stations. Conditions were relatively poor.
The picture is a screenshot of the waterfall graph, with an inset with the decodes. Because of noise artefacts, the times are badly visible, so I put the minutes on the right as well. On top of the waterfall, the sync frequency is marked a green and orange marker. Can you see it? It takes a good look…
A remark: the vertical lines, about 50 Hz apart, originate from interference that is received via the ionosphere. It covers a band of tens of kHz, no idea what it is. It sounds a bit like a running engine.
Note the * symbols next to the messages at the minutes 12, 16, 18, 20 and 23. These decodes were hinted decodes. For an explanation, follow the link at the bottom of the article. Also take these decodes with care, see my notes below.
JTDX has a filter function, that is also a wonderful addition. It limits decoding to a narrower passband around the RX frequency. It improves decoding and also speeds it up considerably. Because of the multiple passes, decoding takes considerable time and sometimes passes the minute, which is too late. If the filter is enabled, it will be much quicker and you will be able to select the correct next message before you start transmitting. I take it for granted to miss possible callers next to my receive frequency.
When I was trying to establish the limits, I experimented with the hinted decoding. When you press that button, the software will activate hinted decoding.
The process flow is as follows:
To illustrate the “risks” of this decoding, let me share an experience.
During my experiments, I transmitted some CQ’s on 60 (not on 5357…) with very low power and received my signals via a web SDR receiver. To simulate a QSO situation, I entered PA2S JO21 in the boxes DX Call and DX Grid.
A day later, when I was experimenting with the web SDR in my office with real life situations, suddenly I saw “CQ PA2S JO21“. I rushed into my shack to see if I my software spontaneously started transmitting… Everything was off, lights were out, very weird… Was someone using my call? Whilst walking back to my office, I realised that my call and locator were still in the two boxes. JTDX had interpreted signals as my CQ.
The takeaway is that one has to be careful and check if the decoded messages are real world or a self fulfilling prophecy…
This is food for the JT haters, but let me repeat that working a station that was spotted on the DX cluster is exactly the same. More about that in the earlier article.
Link to JTDX: http://www.qrz.lt/ly3bg/JTDX/jtdx.html