JTDX Hint decoding

This post has been written in coorperation with Igor UA3DJY.

First of all a short technical explanation of the hint decoder:

Hint is dynamic, it has got 16 logical decoders in 17.5.1 that are using various data: from DXCall and DXGrid windows, from previously decoded intervals, or from CALL3.TXT file. Decoders being focused on some particular messages, some using expected messages logic. This set of messages is encoded the same way software does for message transmission, and each codeword set being compared with the demodulated one using the correlation function.

* Some Hint decoders being turned ON/OFF automatically, and some are wideband, some using frequency mask and some focused on the QSO RX frequency.

* Some Hint decoders being activated by the message transmission, some by RX frequency change and being kept active for some number of the consecutive intervals.

* In version 17.5.1 BM/FTRSD decoder being used first at each decoding pass and even in this scenario Hint decoders are able to compete with FTRSD taking some signals out of the FTRSD view.

* With dynamic Hint implementation now there is no need to load all possible CALL3 + MyCall combinations in the memory, hence now at first interval Hint decoding goes several times faster than at early JTDX versions.

*  Possible messages are direct and reverse reports (30+30), RRR RR73 73, CQ and CQ DX messages. Some Hint decoders do support any directional CQ messages like CQ AA... CQ ZZ.

* For large data blocks created codeword sets being stored in the memory and any RX interval but first one will be decoded fast enough.

* There are two thresholds used to make decision if message is decoded by ‘Hint’ properly: distance between first and second best codewords and absolute value of the correlation function.

* There is the asterisk symbol ‘*’ added to the decoded ‘Hint’ messages, to let user distinguish Hint decodes from BM/FTRSD ones. This symbol is also used to ban sending decoded ‘Hint’ messages to the pskreporter server http://pskreporter.info/pskmap.html , as some of them may be false decodes. However in combination with JT-Alert reports are send to hamspots.net.

* There are unavoidable false ‘Hint’ decodes caused by high sensitivity of the ‘Hint’ decoders, all of them have really existing callsigns in the decoded message. Similar to CW/SSB weak signal reception it is up to user to make own decision if received message is the wrong one.
Number of the false ‘Hint’ decodes depends on linearity of the receive path, signal taken from SDR receiver with digital audio stream have less false decodes, number of the false decodes will be increased if there are intermodulation products in the receive path.



In my first post about JTDX and extra functions I've written about the hint function. I called it a cheat button and doubt I would really use it.  I compared the hint decoder with the master call file you can use in a contestprogram like N1MM and practically it is the same but technically it isn't. Igor wrote me:

'It would be more correct to compare Hint decoder with master callsign file, which many contest participants using to verify some missed letters in the received callsign, but...
in fact it is a decoder that is similar in math functionality to the Reed Solomon decoder and a very simple one.

The difference vs Reed Solomon decoder is that Hint using matched filters and instead of looking for any possible combination of the received symbols it is limited by some number messages that are generated based on DXCall, CALL3 or last decoded interval's data. Reducing number of patterns and applying matching filter allowing to reach  exremely high sensitivity and high decoding speed in JTDX. Some hint decoders can make -35dB SNR decode. Of course high sensitivity bringing false decodes, the same issue has Reed Solomon decoder if we go deeper than -26dB.'

The difference with a master callsign file:

Simply saying Read Solomon is a broadband decoder, 'Hint' are focused decoders. Both are analyzing the noise pattern and both applying math to get the decoded message.

The human brain does a similair thing with the master callsign file: trying to decode CW/SSB signals from noise using callsign focused filters, but the brain does it in reverse order trying to compare a single callsign from master to the noise+signal pattern. 'Hint' is trying to find minimal distance from the noise+signal pattern checking every possible message from the 'master' data, and using thresholds to prevent false decoding.


I know this is a sensitive subject following a story that I did read years ago. However the discussion from years ago was about a module in WSJT called DS (Deep Search) and involved also the file CALL3.TXT in which it searched for fragments of patterns that can be matched with known information  present on the computer only. Some hardliner radioamateurs even banned WSJT/JT65 because of this as they simply didn't think contacts made using deep search were valid (for DXCC). Just to be clear, this DS module is not implemented in WSJT-X as far as I know.

Now Igor has implemented a similair "module" in JTDX that can be switched with the hint button in the software. I'm shure Igor is aware of the issues about deep search and so you as user can switch on/off the decoder yourself, it is your responsibility. If you think it's cheating just don't use it. If you like to experiment and having fun with this software and hobby you can experiment with it as our hobby is all about experimenting.

I am aware of the fact that this post will be outdated soon as Igor is still developing the software. It's important to check regulary if there is a new version and don't forget to read what has been changed.

If you would like to donate to Igor for his work developing this excellent program you can find a donation link on the official JTDX website.

http://www.qrz.lt/ly3bg/JTDX/jtdx.html

Have fun JTDXing...