WSJT-X Invalid ADIF header fix and seasonal change.

I tend to think that the harvest in the field behind GM4FVM marks the end of the Sporadic E season. Looking back, it is a week earlier this year, and two weeks earlier than the year before. Whether the Es follows the harvesting season or not is a matter of debate, but without any real evidence I imagine it is a fact, this is my blog, so there you go.

Harvesting beside GM4FVM on 16 August 2020.

As I write on 23 August 2020 there is plenty of Es activity to the East on 6m. Nothing on 4m where I suspect the Summer Es is mostly over.

I was a bit surprised to work SP1O on 2m on 22 August. He just rose up to +13dB, lasted for the full contact and then vanished. I was heard by many other SP and DL stations according to PSK Reporter, and other GMs heard SP1O. This did not seem to be Es as there was no sign of Es on 4m or 6m, so I thought it was very strong meteor scatter. Or, more likely, it may have been ionisation after a large meteor reached Earth. Anyway, the tone of FT8 was clear but there was the haunting ringing echo which suggested a meteoric cause. On the other hand there was no sign of anyone taking advantage on MSK on any band. So, who knows?

The latest version of WSJT-X, version 2.2.2 has brought various advantages. On FT8 the decoder has improved and is quicker, meaning that we now often see signals decoded before the 15 second rx period is complete. While this is a great advantage, it also opens the door to clicking on the message to initiate a reply and finding a period of silence before tx starts at the beginning of the next period. Great for heart-stopping mini-panics.

v2.2.2 also brought about an improvement to the logging side of WSJT-X. I always liked having "Prompt me to Log QSO" ticked, as this produces a QSO summary. As I use four instances of WSJT-X at once it can get a bit confusing and being reminded to log is a good thing. This also creates an ADIF log file, which I have not used (yet). Contesters use this log file as they tick the box "Log automatically (contesting only)".

Once I started using v2.2.2 it was immediately apparent that a glitch in earlier versions of WSJT had been fixed, and using the log prompt and logging each QSO no longer cleared the "Enable Tx command". Excellent.

Not so good was that another glitch has arisen. Once the ADIF file was created, every time I opened WSJT-X or changed configurations I got an error report: "Error Scanning ADIF Log - Invalid ADIF header".

If you do not use the logging, either prompted or automatic, then you will not experience this problem.

It was not a great hardship to cancel this error message each time I started WSJT-X. But then I have four instances of WSJT-X. More of a snag was having to cancel it every time I changed configuration, which I do every time I change from FT8 to MSK, or to JT65 or JT4 for beacons. More worrying, if the ADIF files created by WSJT-X were invalid I could not use them for logging if I ever need to. Contesters using the automatic logging facility would probably have problems exporting the files into their software.

I worked out that deleting the ADIF files would stop this happening, at least until I worked someone and logged it, in which case it came back again. Anyway, I did that for a while as I tried to work out a solution. The ADIF file can be read in a text editor, so I opened it in WordPad. The way to do this is to click "Open Log Directory", then right click on "wsjtx_log.adi" and select "open with" using whatever text editor you may have. WordPad is not great, but it comes bundled with Windows 10.

Here is an ADIF file I had (as usual click the images to enlarge if necessary)

The header is "WSJT-X ADIF Export<eh>". It needs to read "WSJT-X ADIF Export<eoh>. That is all you need to do, just add one character. Change <eh> to <eoh>.

Next click on "Save" in your text editor.

That's it. Problem solved. Close the text editor and the error message should be gone for good. Unless of course you delete the ADIF file, in which case after you work the next station and log it, a new ADIF file will be created with the same glitch in it. Then you would need to change it again. However, unless you delete the old file, you can probably just leave it as it is.

This is how it looks after it has been fixed, including that rather unexpected contact with SP1O.

I really appreciate what the WSJT-X team have done over the years. In a large software project there are bound to be glitches. In this case we might think that they fixed one issue and created another one. That would be to ignore the other improvements which v2.2.2 brings. The faster decoding will really benefit FT8. Contest working has been improved. I can understand that one letter in one line of code might go amiss. It is easy to fix anyway.

It is well worth updating to WSJT-X v2.2.2 and in general keeping it regularly in step with the latest version.

73

Jim

GM4FVM