Sunday 23 August 2020

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

14 comments:

  1. Outstanding! Thank you for this, the bug has been deviling me for a couple of weeks now, and I have exactly one log entry: my first FT8 contact (as well as my all-time farthest 2m contact at 144 miles!), and I would hate to lose it.

    -73 de Darrell, AE6ZA

    ReplyDelete
  2. Glad to be of some use Darrell. Just shows what FT8 can do for DX! Anyway, it would be a pity to lose it.
    I haven't tried this but you can add to the log entries and export and import them. Must find out how to do that too.
    I have old logs form old versions of WSJT-X which, like you, I do not wish to lose. The snag is that if the log gets very big it takes WSJT-X time to sort through it. So as usual, I dunno.
    Take care. 73 Jim GM4FVM

    ReplyDelete
  3. I was wondering what was causing this pop up. I have several profiles for different rigs; Icom 7300, 9700 and Anan. I will keep this as a handy PDF file...I am sure it will happen again.

    73

    Rafael / NN3RP

    ReplyDelete
  4. I was wondering what was causing this pop up. I have several profiles for different rigs; Icom 7300, 9700 and Anan. I will keep this as a handy PDF file...I am sure it will happen again.

    73

    Rafael / NN3RP

    ReplyDelete
  5. Rafael.
    Yep, the more configuration profiles I have, the more times that thing pops up. You are right about it appearing again, I think it is useful information for anyone delving into ADIF files.
    Glad to be of some use.
    Take care es 73
    Jim GM4FVM

    ReplyDelete
  6. Rafael.
    Yep, the more configuration profiles I have, the more times that thing pops up. You are right about it appearing again, I think it is useful information for anyone delving into ADIF files.
    Glad to be of some use.
    Take care es 73
    Jim GM4FVM

    ReplyDelete
  7. When I looked at the file, I thought looked wrong but that seemed too easy. Working with a new install of WSJT-X on a portable holiday setup and this was driving me a little crazy. Glad I turned to the search engine, this article was the first result. Thanks.

    ReplyDelete
  8. I have been using 2.2.2 (Linux) and the Enable Tx does usually get cleared after making a log entry. I have to manually enable it again after every contact.

    ReplyDelete
  9. I just found this. The problem developed today and was easy to solve editing the adif file.

    ReplyDelete
  10. Thanks for the 'wsjt-x error scanning ADIF log Invalid ADIF header' fix.

    ReplyDelete
  11. Thanks Jim for the help with the error message.
    Quick question, we're using WSJT-X and trying to figure out how to easily export the data to send QSO cards, any advice?

    ReplyDelete
  12. 1. Everybody: you are welcome. Thanks for posting your messages and it is good to know this information did some good.
    2. Sina: I do not send cards myself, except in reply to requests. I do update eQSL from my PC-based log book. I update the logbook (VQLog) manually. I say this first to explain that I might not be the best person to advise you on this.
    However, at the start of using an computer based log I did move data between WSJT-X and VQLog. VQLog is very good and it can print labels for QSL cards and also print direct onto QSL cards. As I say I do not do that myself.
    On those couple of occasions I transferred QSO data from WSJT-X to VQLog. To do this I used "Open Log Directory" and then located the "wsjt-log" in ADIF (".adi") format. I saved this and then used the "Import data" function in ADIF format in VQLog. This worked fine, and I could have printed QSL cards from that.
    While this was OK for moving lots of data a couple of times, say for a dxpedition, it would be pretty cumbersome on a regular basis.
    I understand that is possible to do this on a regular basis but as I do not routinely send cards I have never done it any other way.
    I keep the log in the computer and fill it in manually each time for my own purposes - it helps me keep track of what is happening. I reply to all requests for cards but I am not a big card person so maybe others have more experience of doing this.
    73 Jim GM4FVM

    ReplyDelete