Version 7.13

Horatio Hornblower

I upgraded to version 7.13 and have run into two problems:

Doesn't like Japanese log data (and perhaps other countries).  I get errors on the county, state/province, etc. when validating and the only way out of it is to skip the record.

With Canadian stations that have "Division No. 2" or similar, the program says that the period is an illegal character.

Am I the only one who has experienced this?

Also, while I have your attention, When i validate my logs from LOTW, I get a horrendous number of records with a mis-match of zones.  Any clue as to why?

BTW, I use QRZ to obtain station data for my logging programs.

Thanks and 73


XMLog Support

Hi Bill,

   I've just done a major overhaul on XMLog's county handling that should address some of these issues.  These changes are available in version 7.14 at

   Give this a try and let me know the results and we'll see if more tweaking is required.

Mike - W1ECT

XMLog Support

Hi Bill,

   Have you had a chance to try the beta version of XMLog (7.15) at to see if it helps with your problems?

   It should deal with the Japanese county information in LoTW records and not give any errors.

   It should also fix the complaints about the "." in the Canadian county names.

   I don't know why you're getting so many zone mismatches showing your log data not matching the LoTW values.  I suppose the Callbook values may be out of date or incorrect.  The main mismatch problems that I see for state/zone/grid values are caused when it seems like the guy submitted his whole log to LoTW using his current location values when actually his log contains QSOs from different locations as he moved around.  When I originally tried to apply LoTW to my full log file of 27,000 QSOs I got hundreds of mismatches for states and zones.  You could see what was going on especially for contest QSOs -  the incoming LoTW state/zone data would match the current Callbook values but when I checked the "wrong" values in my log I could see that my data was actually correct because it matched the info that the guy passed me in the contest exchange.  So, how to deal with this?  Should I ignore the incoming values and keep what I had in my log?  Well, as far as the ARRL is concerned for awards etc. the LoTW values are the correct values, so I just bit the bullet and chose to accept the LoTW values when I applied the LoTW file to the log (quite a tedious process).

   A couple more thoughts here

      - If I didn't switch to the LoTW values but kept my current log values I would see these mismatches again when I re-applied that data at a later date.

       - If the guy updates his LoTW data with the "correct" value for those old QSOs, I'll see a mismatch on some future application of LoTW data and I can choose to use those values!

   LoTW lets you set up multiple profiles with different callsigns and locations.  This is designed to handle callsign changes and station relocations.  For my LoTW account I defined profiles for WN3ECT, WA3ECT, WA3ECT/1 and W1ECT.  I then I uploaded the appropriate subsets up my log for each call/location.  A real pain and I suppose that's why not many people go to the trouble.  They just load all those old QSOs using their current (incorrect) location.

Mike - W1ECT