Sked with M0YKS

Another sked with a blogger I've been following for years. M0YKS Simon from Bradford England has started a blog more then 10 years ago and has been a example for my blogging about the hobby. Simon and I both are in busy family life but we found time to meet each other on the frequency. Had a great QSO with Simon for almost a hour on 80m. We have several common interests hobby and family wise. Great to have a QSO with you Simon. Here is a surprise:

I see Simon already posted his version of the story. Wow, what a signals. Never seen myself as a big gun station hi. Doing a fine job yourself as seen in the video.

PACC 2017 review

Event: PACC 2017
Section: LOW power SSB
Logger: N1MM+ latest version
Station: Icom IC-706MK2G at 100W
Antenna 1: 84m horizontal loop @7m agl
Antenna 2: Coppertape vertical (7,1m)  @9m agl
Antenna 3: 10m HB9CV @6m agl


I worked QRP in the last 2 years, a choice I had to make as I was not able to participate full time. This year I was able to spend more time in the PACC contest and so I choose the low power (100W) section. Unfortenately I was not able to start at time and when I started I had the idea there was no one on the bands. Watching the time I knew the contest has started but propagation was just that bad. The first hours of the contest was hard work. The only station that could be worked easily was TL8TT (Central Africa Republic) on 20m, 17m and 15m a first 2017 ATNO for me.


Then it occured to me that my output power was less as normal I suspected the voicekeyer and when I disconnected it everything was allright again. It gave me also problems with RF on my modulation on 15m. I had those problems before and last week I soldered a isolation transformer in the audioline just to prevent these things. I removed the transformer, connected everything like it was before and next problem was a big hum on the modulation. Opened the voicekeyer again checking every connection, couldn't see anything wrong, still a large hum. I didn't want to do the rest of the contest without a voicekeyer as most of the time I would call CQ especially deep into the night. I went on a half hour calling including hum, at least the modulation was ok. But I was not really happy with the situation so after opening it a third time I had the idea the printboard was not in good position and might be having a connection with the alu box chassis it is in. Not shure about that, but I took especially care to have it in good position when closing the box again and this time all problems were over. Of course this took me more as a hour valuable contest time. At sunset I just had 75 QSOs in my log a absolute minimum, that means only 15 QSOs in a hour average. My hopes for a reasonable score were gone.

Still it was not only disaster in the radioshack, I worked my share of DX in the mean time. Invaluable multipliers were the contacts with TL8TT on 20 and 15m (probabely not counting for the contest), PJ4DX (Bonaire), PY5AB (Brazil) and K3ZO/WX3B (USA) on 15m. I even worked a second multiplier on 10m with PY5QW (Brazil), again proof that my 10m HB9CV is amazing! When it went dark 20m became dead soon and the low bands came to life slowly. 40m didn't show the best ever although some contacts were made there despite of the RTTY QRM. 80m was quiet even at the best time slot (19:30 UTC) and I moved to 160m which was quite open to my surprise. I started to call CQ after a small S&P and it amazed me how many came back to my tiny signal. Even 5B4AIF on Cyprus answered my call (worked him on all bands except 10), I'd call that DX for my modest setup (160m only on the vertical). As you can see in the graph the rate jumps skyhigh midnight to fall down quickly after. I went to bed at 01:30 UTC and was there again at 6 UTC. I don't think I would have made many QSOs at nighttime, although you never know. I did 99% running at 80m and best DX that got back to me was PJ4DX (Bonaire) and K6ND (near Boston USA) as always 80m was my best band by far with 227 QSO made.

Some things during this contest that should not occur:

* N1MM+ disconnected the radio when I quickly tuned over the band. Or jumped with the keyboard from station to station in the bandmap. It just lost the connection and I had to reset to get connection again. It happened at least 10 times and not during transmit (no RFI). Connection between N1MM+ and the radio always has been a issue here and it seems it gets worse in every new update. I don't know what causes this, HRD never gives me a problem.

* I mysteriously lost some logged calls. I know for shure I logged them and the next moment I log another station the station before that QSO is gone. Happened 3 times so I lost 3 QSOs. Can't remember their calls. There was at least one UA that I lost. Not shure what is the cause of this as well???

* I worked a lot of dupes. Oh yes they were in my log and I don't argue when contesting, I just logged them. 10 dupes in a reply on my CQ!!! Never worked 10 dupes ever in a contest! Anyway, 2 QSOs gives at least 50/50 chance I am in the log with a correct call.

I learn from every PACC contest. Sometimes you got luck, sometimes it is just stupidity and sometimes you really can't do anything about it.

Looking forward to the next time....

PACC preparations

Running out of time....sometimes you can't help it.

As the PACC contest is ideal to test new or experimental antennas I have been dreaming of setting up a experimental "high" inverted-V antenna for 40m fed by open line so I could use it on other bands as well. But it went no further as dreams, I had absolutely no time and still have to hurry to prepare myself for the PACC. I just updated N1MM+ this evening, inserted the PACC contest and tested the radio and equipment. All seems to be working. The only problem is I didn't hear much SSB signals from 40m and up. The only bands open were 160m and 80m. That doesn't sound/look good for this weekends PACC contest...

Well, last week was not the best for us. We had a big problem with our central heating installation. This is a big problem in the winter of course with temperatures below 0 degrees celsius. In the Netherlands it is common to have a boiler which is powered by natural gas. This gas has been found below the province I live in around 1959 and became a big income for our country. We dutch are very much spoiled with this kind of heating and in most houses it is just a matter of turn the thermostat and you got heat. Last year in Denmark I discovered the house we were in was only heated by electricity and wood, no gas. A strange discovery for me and I have been thinking what are common heating systems in other countries around the world. Here this natural gas well is almost gone, it's used and we knew for years this would come to an end. Still they try to squeeze the last gas out of it and that causes a lot of problems in this province (earthquakes, lowering groundlevel etc.). Anyway, that's another story. Our heating installation is from the early seventies and made of unprotected steel tubes. It got rotten and tubes were leaking last week, al lot of trouble because the tubes were below the bathroom under a 50cm layer of concrete. Luckely we managed to make a emergency connection to the house with the help of a central heating technician. However part of the house is not heated at the moment and it is just the part below the radio shack. So, hopefully a couple of hours contesting will heat the shack a bit as outside it stays cold, freezing cold. I feel lucky my shack has been isolated very well although temperature this evening was 5 degrees.

If time allows I will check antennas tommorow and push up the 10m HB9CV. I don't think I will work much on 10 but you never know? My feeling is that the majority of QSOs will be on the low bands this contest....

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.

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

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.