Wednesday, February 8, 2017

PACC 2017 upcoming weekend

Event: PACC 2017 contest
Modes: SSB/CW
Date: 11-12 Febr. 2017 12:00-12:00 UTC (24hrs)
Exchange: RS(T) + Province abbriviation of 2 letters, foreign: RS(T) + serial starting at 001
Foreign rules: https://pacc.veron.nl/foreign-rules/
Dutch rules: https://pacc.veron.nl/dutch-rules/

The PACC contest is the most important contest for Dutch radioamateurs. The nice thing is that everyone has to work the Netherlands so we dutch HAMs finally get a response on a CQ when calling. The only problem is that the CQWW WPX RTTY contest is going on in the same weekend. That means all the important big contest stations outside the Netherlands are not participating in the PACC unfortenately. Anyway, that doesn't matter as the PACC is a fun contest and if you send in a log with your address you will receive a very nice token of merit. I don't know of any contest that sends such a token and it is much appreciated.

Hopefully all of you readers will participate. Although not everyone likes to contest of course.

Friday, February 3, 2017

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...


Wednesday, February 1, 2017

Impressive JTDX performance

I got a e-mail from Igor UA3DJY today. Followed by a short e-mail discussion. He did read my blogpost and asked me to evaluate 2 WAV files to show what the AGCc is actually doing. Besides that he explained the hint decoder to me which I will save for another post. I downloaded and installed the latest version of JTDX (17.5.1) and did some tests which were impressive, really impressive. Remembering the comment from Paul PC4T that he had better results with WSJT-X receiving the same time with both JTDX as WSJT-X. So I did some tests with WSJT-X to compare receive capability with the same WAV files.

First wav file:


Above the screenshot from WSJT-X 1.7. No more, no less. 3 decodes. I tried other input levels and repeated the pass, still I got the same 3 decodes.

Above the screenshot from JTDX 17.5.1. As JTDX has more possebilities I used them in the following order (clicked decode after switching filters): Without any filter 3 decodes but different from WSJT-X.  I switched on the AGCc and decoded 10 stations including those that were decoded with WSJT-X. 3rd pass AGCc still on and SWL on no difference and still 10 decodes. With AGCc, SWL and hint on still no difference. As you can see the strong signal will push away any other weak signal from decoding, with AGC compensation those will be decoded.

Second wav file: 

Above the screenshot from WSJT-X, look at the waterfall with many signals near to each other. As with the first wav file I tried several times with different input levels. Still the best it could do was 3 decodes.

Above the screenshot from JTDX 17.5.1. 11 decodes without any filtering, isn't it amazing?
Wait, now comes the impressive AGCc on and decoded 14 stations. AGCc and SWL on gives still 14 decodes. AGCc, SWL and hint on.....15 decodes, note M6YPZ the last decode has a star behind it as a sign it was spotted with hint decoder on.

What AGCc does is to compensate the loss of weak signals when a strong signal is received. Any receiver with AGC will reduce gain to prevent strong signal(s) will make signal distortion. Actually most modern receivers will do that. I think this is especially useful with strong ES propagation on 10m in summer.

2-2-2017 Supplement from Igor UA3DJY: 
In fact AGCc function trying to reduce noise level at beginning and end of the interval so that it is equal to the noise at the signal reception.
It is needed to provide correct operation of the correlation function being used in WSJT-X/JTDX. 
While AGC being triggered very often on the HF bands AGCc functionality lets to decode more signals.

When I tried this compensation only for JT65 signals I had got a bit better results, but later I have had to move this functionality upstairs in the source code to cover both JT65 and JT9 signal reception.

73 Igor


Compare VK7XX -16dB in WSJT-X and -15dB in JTDX, LU8HGI -20dB in WSJT-X and -22 in JTDX, IT9CCB -15dB in WSJT-X and -14 in JTDX. Overall signal reports are close, but how important is a signal report if you don't receive anything at all?

My conclusion: the AGC compensation works pretty well. But of course to show that it is working you need at least 1 very strong signal on the frequency.

I hope this is a objective test. If any reader is not shure about my evaluation capabilities let me know. If you want to test the wav files yourself I would be happy to send them to you for a second opinion so to say.