ZM4G glow logo
ZL2iFB glow logo
Tokyo HyPwr
TS850 mods

Quick links

  1. Evaluating logging programs using a structured method to choose between them
  2. Logger32’s features, snags and bugs - the highs and lows of an excellent logging program
  3. HamQTH lookups - using Logger32’s built in function
  4. MMVARI - soundcard data software integrates with Logger32
  5. WSJT-X - automatically transfer your FT8, JT65 and JT9 QSOs to Logger32 as you log
  6. Logger32 hack: highlight arbitrary calls - ‘repurpose’ Logger32’s call-lookup function
  7. LogPrint - an add-on for printing QSL labels
  8. Using Logger32 with LoTW - uploading QSOs to LoTW, downloading QSLs and DXCC records
  9. Using Logger32 with the Elecraft K3 - a few hints for Elecrafty users of Logger32

This page is mostly about computer logging using Logger32 by Bob K4CY.


Evaluating logging programs

Having emigrated to ZL in 2005 and re-started my DXCC hunt with a shiny new ZL callsign, I decided this was the ideal opportunity to start computerised logging. My paper G4iFB logbooks and shoe -boxes of G4iFB QSLs are now turning yellow and collecting Kiwi dust on a shelf.

So, how to choose a logging program?  I’m used to evaluating software for work so decided to apply the same process:

  • First, I determined my requirements and listed them out, taking suggestions from fellow DXers in CDXC. These became my evaluation criteria. *
  • Next, since some requirements are clearly more important than others, I prioritised and ranked them to generate “weightings” for each one. *
  • I put the criteria into a column of a spreadsheet, adding columns for every logging program I could find and a column with the weightings.
  • I obtained evaluation copies of several logging programs and entered the scores for each one against each of the criteria, adding notes to explain why they scored as they do.
  • The spreadsheet calculates a percentage rating for each program by multiplying each of the scores by the corresponding weightings and totalling. Easy peasy.

* Please note that both the criteria and weightings are personal to me. They reflect my priorities, what’s important to me in how I intended to use logging software. I’m confident the spreadsheet is of general interest but your requirements probably differ somewhat from mine, in which case you are very welcome to download the spreadsheet and adapt the requirements and/or adjust the weightings to suit your purposes. Just because I chose Logger32 doesn’t necessarily mean it’s right for you!

The evaluation spreadsheet is a useful starting point. If you use or evaluate any of the logging programs listed on the spreadsheet, or indeed others, and are willing to share your scores and comments by updating the spreadsheet, please let me know. All inputs are welcome. I’m especially keen to hear about logging programs that you feel score above Logger32, preferably using my criteria and weightings!  I encourage heavy, long-term users and ardent fans of any logging software to explain why you love it so much. Tell me more!

I have chosen to use K4CY’s Logger32 for my everyday station log and N1MM for contest logging. Both programs are free and support the ADIF XML log standard, meaning that after a contest I can integrate my contest logs from N1MM easily into Logger32. ADIF also lets me export logs to other programs if Logger32 doesn’t do what I need it to do, although I have noticed differences in the way some program interpret the ADIF standard so it can be a risky process. Whatever else you do, take frequent log backups and check them to make sure all the essential QSO information is in fact being backed up!   ADIF files are plain ASCII text, so you can open them with Notepad to browse through and edit. Check that your latest QSO appears at the bottom, and that the details such as UTC date and time, callsigns (both the DX and you, as operator), band and mode are all correct.

ADIF or Cabrillo output is essential if you use ARRL’s Logbook of The World, which I heartily recommend (it’s one of the heavily-weighted criteria in the evaluation spreadsheet). The Web interface to LoTW is somewhat clumsy and the initial registration process laborious but it’s worth it in the end to have such rapid and cheap electronic confirmations of QSOs with thousands of other LoTW users, in a secure manner, and an easier way to claim the ARRL’s DXCC and WAS awards, plus CQ Magazine’s WPX and WAZ awards.

Back to quick links


Logger32 features, snags and bugs


Logger32 main screen 740

Logger32 is an excellent logging program with loads of useful features such as:

  1. It’s free, as in free beer not free speech. The author and support team put a huge amount of work into writing and maintaining the program and expect almost nothing in return (although understandably they get grumpy if you ask dumb questions that are answered in the documentation!). Kudos to them for their true amateur spirit and for responding positively to reproducible bug reports and improvement requests from users (well some, at least: they have their priorities too!).
  2. It follows the latest ADIF XML standard closely, allowing me to exchange logs easily with other ADIF-compliant programs such as N1MM+ and LoTW.
  3. It competently handles the basics - things such as entering and storing QSO information, displaying country info, beam headings, times, previous QSOs etc. Logger32 is fast enough to keep up with me, even in pileup situations.
  4. The screen layout can be customized to show windows such as the logbook, DXcluster, greyline map, log entry screen, notes and more, all on the one screen (such as the screenshot above) or spread across several (e.g. I now monitor the band maps on a second screen while working, catching up with emails, browsing the web etc. on the main screen with Logger32 in the background until some juicy DX catches my attention). The layout, sequence and colouring of most windows and the highlighting to show DXCC and QSL status can be customized.
  5. L32 annual all time toggleIt tracks our DXCC worked and confirmed statistics automatically, and has a handy function to switch between DXCC stats for all time or just for the current calendar year. Clicking the top left corner of the Worked/Confirmed window toggles between all-time and this-year-only. In the example shown here, I see that I had worked HA (Hungary) on all bands and modes over the years, but only on 2 bands in CW so far in 2015, neither of which had been confirmed. The toggle setting also changes the highlighting of DXcluster spots accordingly. This is ideal for the CQ Marathon and annual league tables such as those in Clublog.

  6. It’s extensible with several useful third party add-ons written and released by other talented and generous hams.
  7. It has additional features such as the Digital Voice Keyer function. From an icon on the main screen, I can trigger replay of the voice messages stored in the K3’s optional DVR hardware - handy for calling DX in an SSB pileup without constantly reaching for the rig or shouting into the mike like a demented parrot. [The ‘radio control panel’ function lets me send arbitrary commands to the radio - even better!  I can compose and test new K3 macros on the fly.]
  8. Another useful additional function gives integrated access to MMTTY and MMVARI combining QSO logging in Logger32 with waterfall/Lissajous display, decoding, memory replays etc. from MMTTY/MMVARI.Logger32 now uses Club Log’s wonderful DXCC info database maintained by Alan 5B4AHG, to identify the correct DXCC countries, both in near real time as we are logging QSOs (using a daily update from Club Log) and subsequently (checking logged QSOs for their DXCC status at the date and time they were logged).
  9. It can link to WSJT-X, JTDX and other digimode software via UDP, receiving QSO information into the log, updating statistics etc.

However, like all software, Logger32 is not totally free of issues. Here are the snags that bother me the most - a mix of what I consider design flaws, bugs and things it just doesn’t do, in decreasing priority order at least as far as I’m concerned (your priorities probably differ):

  1. Pointless confirmation clicks are annoying, especially in the program functions that I use frequently (e.g. LoTW and Club Log updates  through the otherwise very useful L32 LogSync utility from N2AMG). Logger32 sometimes pops up a selection panel even when there is only one option. From a usability point of view, it would be nice for the user to at least have the option to drop unnecessary confirmations (perhaps a “Do not bug me with this again” option?). And yes I know that’s one more click!
  2. Dupe spotsIf a station is spotted on DXcluster but then moves from, say, a busy to a clear frequency in the same band and is spotted again, the band map shows the spots on both frequencies , until the earlier spot times-out and evaporates anyway. In the example seen at right, ES2JG was spotted twice on 40m CW: if for some reason I haven’t been observant enough to notice the sequence of spots, which one should I go for first?  Come on, hurry up with your answer since both are highlighted as new band slots!  The band map configuration option “Show multiple spots for a callsign” was unchecked  in this case, which I would have thought implies “Don’t show multiple spots for a callsign” but, no, apparently not. Admittedly the logic is a bit tricky because multi-op DXpeditions may transmit more than one signal on a band at once, though almost always on different modes in different band segments. Logger32 evidently can’t figure out the difference between a single station that moves and is re -spotted on the same mode, and one that is simultaneously transmitting on different parts of the band on different modes. Doh!  So much for AI!
  3. The logbook can be sorted by several fields. The sort happens quickly but does not leave the cursor and display on the previously-selected QSO line right after the sort, which is the Windows default. [For example, with the cursor sitting on a G3SXW QSO, if I sort the log by callsign, it should finish up with me still looking at that same G3SXW QSO but with the logbook now in sorted callsign order around it.]
  4. Logger32 help unblockAlthough Logger32 can check for program updates automatically as it launches, those updates do not include updates to the help files (‘in order to reduce the download size’ is the support team’s explanation).

    Every so often, we must remember to download and install the latest help file manually from http://www.logger32 .net/support.html#help.  Download the most recent .chm file (a compiled HTML file), then move it to your Logger32 program directory (usually C:\Logger32).  Right-click the file and click Unblock so you can open and use it  -->

    While you are at it, delete any .CHI files remaining in the Logger32 directory, left over from old versions.

    Users who neglect to do this (generally because they don’t realise they need to ) often complain on the Logger32 support forum that they can’t find anything in help about recently -added/changed functions ... because their help file is woefully out of date.

  5. Having added the appropriate data entry field to the log entry window, I can enter an American’s two-letter state abbreviation easily while I’m having the QSO  but the method of entering US states and/or counties for stations already in the log (e.g. from info on their QSL cards) is awkward, requiring a right-click on the log line, select “Edit Admin Subdivision info” , select the state or enter the 2-letter code, then select the county, then click Apply. For QSOs that already have a state but no county entered in the log, it’s necessary to open the same “Edit secondary admin info” screen and click the already-highlighted state line to bring up a list of counties in that state. [Unnecessary clicks again]
  6. In Logger32, it is possible  to create an ADIF file listing DXCC countries confirmed by QSL card but not by LoTW, for online DXCC applications . It’s not easy though. See the LoTW page for instructions. It would be nice if this process could be simplified.
  7. While entering a callsign to log it, the entry field expands with a list of partially matching calls previously worked and in so doing partially occludes the country info and beam heading (although that info is still shown in the status line at the bottom of the screen). The ‘previous calls’ box can’t be moved, reduced in size or made partially transparent so the only way to clear it is either to continue entering characters until there are no previous calls to find, or to turn off the ‘callsign preview’ function completely.
  8. The process for changing the layout and content of the logbook window does not follow the Windows conventions. Instead of simply being able to drag columns around on the screen and hide/reveal them, we have to enter a separate configuration screen, then carefully drag the relevant fields into the right sequence while avoiding crossing other items already shown. This is not unlike threading a needle with the mouse, tricky enough for this able-bodied computer user but must be next to impossible for physically-handicapped hams. On the upside, it’s an infrequent set-and-forget operation and the screen layout settings are retained through program updates.
  9. Logger32 won’t let us select multiple QSOs to make bulk changes e.g. to fill-in missing reports, change the QSL status, change the operator, fix busted zones etc. It is a one QSO at a time program. On the upside, we can only screw up one QSO at a time.
  10. Logger32’s NCDXF beacon tracking facility is useful as it is but a few little changes in this facility would be nice. At present, the status of the individual beacons can be manually configured, requiring us to select the relevant beacon from a drop-down list, then click to toggle the active status flag separately on every band: since a beacon is generally QRV or QRT on all bands at once, an option to set or reset all the bands with just one click would be nice. Even better would be for Logger32 to look up the status info from the NCDXF website for us and set the flags automatically, maybe when the NCDXF beacon window first opens on any day.
  11. Unlike, say, AClog, there is no automatic function to download and recreate Logger32’s log from LoTW in case you lose your log and have no backups (been there, done that!).  However don’t panic: if you are desperate, it is possible to download your basic log info from LoTW as a minimal ADIF file and then import it into Logger32 - see my LoTW page for details. Clublog offers a similar download-your-log function.
  12. When synchronizing LoTW confirmations with my log, Logger32 refuses to accept at least one valid primary administrative subdivision, namely  “DC” for the US District of Columbia:

    DC is not valid says L32

    DC is a valid state

    That is part of the list on the official ADIF website so (regardless of whether you believe DC is truly a state) it is definitive in the context of ADIF, hence should not be rejected by Logger32. Logger32’s lookup list is evidently incorrect.
  13. Logger32 also rejects several secondary administrative subdivisions, although to be fair the official ADIF specification is unclear and ambiguous on some of them - for instance are the ‘independent cities’ in Virginia and Nevada (such as Carson City, NV) valid or not?  The ADIF spec identifies two lists of counties, CountyHunter and FIPS 6-4:

    ADIF spec for US counties

    The CountyHunter site is very ambiguous re the validity of the ‘independent cities’, saying they are “not taken into account” (so: are they valid or invalid?):

    CountyHunters ambiguity over cities

    And the FIPS 6-4 standard (withdrawn by NIST way back in 2002!) was also ambiguous on the way to express Carson City (or is it “Carson city” or just “Carson”?):

    Deprecated FIPS 6-4

    Similarly, Logger32 rejects Anchorage as an Alaskan secondary subdivision:

    Anchorage is invalid says L32

    but it is valid according to the ADIF site:

    Anchorage is valid says ADIF site

    and it has the same problem with a few others e.g. Kenai Peninsula and Masanuska Susitna (both also valid Alaskan areas) and several Asiatic Russian and Chinese areas e.g.:

    PM is invalid Asiatic state says L32

    PM is valid Asiatic state says ADIF

  14. The LoTW-to-log synchronization process has a useful automatic synch option that updates logged QSOs to show if they have been confirmed on LoTW. It generates a confusing flurry of messages about the updates, initially stating that a bunch of records have been updated, then saying that some of them had mismatches and directing us to check the file LoTW_mismatch .txt for details.  Here’s an example record from the mismatch file:

    The following data in this LoTW sync record does not match the QSO in your logbook ...
    GRIDSQUARE field mismatch: Logbook field = ,  LoTW sync field = EL29ll
    CNTY field mismatch: Logbook field = ,  LoTW sync field = TX,GALVESTON
    LOTW_QSL_RCVD field updated.

    That final line is a tad misleading: to me, it implies that only the named field has been updated whereas in fact others have also been updated - specifically the US state and county and grid square in this example, the fields noted as non-matching in the previous two lines.  All in all, I find it an unhelpful mess of messages that I would prefer not to see every time since the QSO records in my log are in fact updated in accordance with the options chosen on the earlier pane.


There’s more on various Logger32 add-ons below, and I’m very slowly compiling a minimalist ‘unofficial’ Logger32 FAQ to which further inputs are very welcome. Meanwhile, here’s a parting thought from P Williams that perhaps explains how Logger32’s users are perceived by the program’s long-suffering author Bob K4CY:

“From the programmer’s point of view,
the user is a peripheral that types something
when you issue a read request”

Back to quick links


HamQTH callsign lookups

Logger32 offers two automated ways to lookup information on stations as you are logging them: a ‘built in’ function or by calling an external program (such as N2AMG’s utility to handle lookups).

The built-in function works nicely with To set it up:

  1. Visit and register. Preferably while you are there, lookup and check/update the info page for your own callsign/s.
  2. In Logger32, go to Setup > Autolookup  and select Auto Internet Callsign Lookup (internal).
  3. Start entering a QSO in the log entry window in order to pop up the lookup results window.
  4. HamQTH internal lookupsOn the lookup results window, go to Toolbox > Change lookup URL (as shown here). Insert the relevant URL in the form:

    where your_callsign and your_password are your login credentials for
  5. For bonus marks, while you are on the lookup results window, go to Toolbox > Change Window caption and change it to something approximating HamQTH.

I prefer HamQTH to lookups for three reasons:

  1. HamQTH lookups are generally quicker;
  2. There is no need to install, configure and frequently update an Logger32 add-on;
  3. Most of all it is FREE: HamQTH is supported by advertising income and donations from happy users. QRZ also receives advertising income and donations but charges for XML lookups, unless you settle for slow and unreliable HTTP screenscrapes.

Back to quick links


MMVARI & Loggger32 integration

MMVARI is an excellent soundcard data program by JE3HHT. While it can be run as a standalone program, it has the necessary hooks to allow it to be called from within Logger32 and N1MM’s logging software. The key advantage of doing so is that you can log contacts simply by clicking on the relevant details on MMVARI’s decode screen. Furthermore, ‘new ones’ are colour coded as they arrive on the decode screen.

MMVARI works nicely on RTTY, PSK and a few other digimodes.

The cool MultiRX feature simultaneously decodes multiple signals within the audio passband, in much the same way as DigiPan and WSJT-X.

Having flapped around in help desperately looking for the correct Logger32 macro command to include the time in a RTTY contest exchange (no, not $time$ - that would be far too obvious!), I wrote this one-page crib-sheet for some common Logger32 soundcard macros (in MS Word in case you want to customise it) and here’s the PDF version. By all means send me your improvement suggestions. There are many more macro commands available - to check them all out, in Logger32 simply open help then click the Index tab: macro commands start with a $ and so are listed at the top in alphabetical order.

Back to quick links


WSJT-X/JTDX & Logger32 integration

WSJT-X and JTDX are not Logger32 add-ons but standalone programs for using the digital modes such as FT8 and JT65. The programs can generate an ADIF log of the digi QSOs we make but the logging functions are minimalist compared to, say, Logger32.

Logger32 can link up with WSJT-X and JTDX via UDP in order to log QSOs as they are logged in WSJT -X/JTDX, and to generate a kind of band map showing the digital stations recently decoded by WSJT -X/JTDX.

To set up the UDP log-update facility:

  1. In WSJT-X/JTDX, press F2 to open the Settings and confirm that you are using the defaults localhost address and UDP Server port number 2237 :
  2. WSJTX Settings reporting

    If you want to initiate FT8 QSOs from Logger32’s UDP band map, select the UDP options shown to allow Logger32 to send commands to WSJT-X/JTDX.

  3. In Logger32, right click the UDP option currently in red on the lower status bar, then select Click to Open UDP socket .  That starts UDP listening on port 2237 by default, turning the UDP option blue with a popup confirming that it is ready to receive UDP messages. 

    L32 UDP listener

  4. Right-click UDP on the status bar again, then select Open UDP BandMap to display the band map.  Drag and size it to your liking: find or make a suitable space on your screen to keep an eye on what’s happening on FT8. This is roughly how the UDP band map will look after you’ve configured the options (see below):
  5. L32 UDP band map

  6. Configure the UDP band map to Allow automatic QSO logging , and set up the other options (colours, font etc.) similar to your other band maps for consistency and ease-of-use.

    L32 UDP band map config

    ARRL grid chaseI find a 2 minute timeout (under Set decoded callsign visibility) works well for me when FT8 is busy. I like to see Gridsquares, mostly to find the rarer American states such as Vermont (grid FN32, 33 or 34), Maine (FN54, 55 or 56) and the Dakotas (DN82 -88 or DN92-98) and to participate in the ARRL International Grid Chase in 2018.  I still chase global grids today. “Wet grids” activated by maritime mobile stations are the real challenge now.

  7. Enjoy!  Having made a QSO in WSJT-X/JTDX and logged it there as normal, it magically appears in your Logger32 log shortly after.  New QSOs will be uploaded to Club Log at the same time if you have made that connection, and your Logger32 statistics are of course updated in the normal way.

Back to quick links


Logger32 hack: highlight callsigns in an arbitrary list

Logger32 has a built-in function to check whether calls spotted and logged are using LoTW. It does this by downloading the LoTW user file, importing the callsigns from that file into Logger32’s database, doing lookups when spots are filtered and displayed from the DXcluster or when we are logging a call.

While it quite a useful to know who is using LoTW, I already have that information since VE7CC’s Cluster User program does the same checks, marking spots for LoTW users with a plus sign in the comments field. Furthermore, previous QSOs that have been confirmed on LoTW are identified with a coloured background in my logbook. In short, I don’t need Logger32’s LoTW lookups.

I thought it would be more useful to know when my friends from FOC are spotted, so I set about fooling Logger32 into loading a list of FOC members into its LoTW function, instead of the list of LoTW users.

L32LoTWuserHack barsWhen I run the “Import LoTW users” function in Logger32, it saves 4 files in the Logger32 directory (unfortunately - good practrice would be to use a separate data directory): LoTWUsers.txt, LoTWUser32.isd, LoTWUser32.isf and LoTWUser32 .ism. The latter 3 files are the database in which Logger32 saves its lookup info. LoTWUsers.txt is a plain text file of calls of LoTW users. Simply replacing that file with a list of FOC members’ callsigns and restarting Logger32 made no difference to Logger32 since it  was presumably using its internal database rather than the text file. I needed a way to make Logger32 import the FOC calls into its database, in place of its list of LoTW users. The answer was to alter the URL through which it downloads the LoTW users file.

So, here is the method step-by-step:

  1. L32LoTWuserHack in progressGenerate a plain text file listing all the FOC members' callsigns, one per line, and save it as C:\Logger32\FOC .txt (on the root directory on C:).
  2. In Logger32, right-click in the main body of the DX Spots window, select Setup --> Load LoTW users file.
  3. In the Download LoTW users file window that appears (see right), replace the URL on the top line with file://C:/Logger32/FOC.txt and yes those are forward slashes because it is a URL not a Windows file reference. If you saved the data file in a different directory, good luck figuring out the syntax.
  4. Click "Download from Internet" to make Logger32 suck -in the FOC.txt file, thinking it has just downloaded the LoTW users file from HB9BZA.
  5. Click "Save file" for Logger32 to save the FOC calls to its internal LoTW user database.
  6. L32LoTWuserHack tickMake sure Logger32 is configured to identify (what it thinks are) LoTW users by right-clicking in the main body of the DX Spots window, then go to Setup --> Appearance and confirm that "Show LoTW user" is ticked.
  7. Watch in awe as incoming DXspots for FOC members are marked with a little bright green bar in the far left margin of the DX Spots window (see the screenshot above), and gasp with delight when a tick appears in Logger32's log entry window while you are logging an FOC member (see right).

This works great for FOC members whose spots appear in the DX Spots window. However if you have configured Logger32's spot filter to filter out cluster spots that are not 'new ones', then unfortunately it will only show and mark spots for our more exotic FOC members identified as 'new ones'. Logger32 will still show the tick when logging any FOC member on the list.

[The text file it uses for lookups can of course contain any callsigns, not just FOC members. The same process would work for, for example, lists of friends or club members.]

If you only want to identify a few calls whenever they appear on DXcluster, the audio alerting function (accessed by right-clicking the DX Spots window, then selecting Setup --> Audio alerts --> Enable audio alerts) accepts a list of calls. I have used this facility to flag stations in CQ Zone 2.

Back to quick links



Prior to signing-up with GlobalQSL, I used LogPrint to print labels for my QSL cards. The program is a pig to set up by trial-and-error but I found a combination that worked. Rather than start from scratch, feel free to download and adapt my LogPrint.ini file if your setup is similar to mine. On Windows 8.1, LogPrint tucks its .INI file away in the directory AppData/Local/VirtualStore/Program Files (x86)/LogPrint.

For the Impact LC16 labels (2x8 labels per A4 sheet with no label margins), I use tLogprint label size 2x8he label size shown here. The vertical pitch setting is critical - just a fraction larger and the last labels on the sheet wrap to the next sheet. A fraction smaller and the printing doesn’t align with the label boundaries.

K5LAD has a helpful web page showing how LogPrint’s “fields” are used to layout the individual labels. I’m using 14 of the 15 available fields to print up to 3 QSOs per label:

Logprint label setup

Logprint label sort options

Cards need to be sorted for the bureau in alphabetical order of the recipient’s callsign, whether that is the guy’s QSL manager or his own call. LogPrint’s sort function handles that OK if set as shown here.


Rather than print directly from LogPrint to the printer , I print to Adobe Acrobat first since Adobe lets me tell the printer I’m using label stock, and I can print or re-print individual pages if (when!) they don’t feed properly.



The finished article looks roughly like this (complete with typo on the card - ZM4T is the club’s call not mine!  For some reason the printer decided ZM4G was wrong and changed the call without telling me, and I didn’t notice his mistake when proofreading. Doh!):

QSL card label example

Back to quick links


Using Logger32 with Logbook of The World

ARRL’s LoTW is a robust, secure system for cross-matching electronic QSO details to generate electronic QSLs. LoTW incorporates controls to minimize the possibility of fraud and [data] corruption. Logs must be signed using public key cryptography and digital certificates issued by ARRL. Unfortunately, that makes the manual processes of uploading logs and downloading QSLs rather laborious - exactly the kind of thing that computers are good at, one might have thought. More on that later.

Before you can use LoTW, you need to obtain and install your digital certificate from ARRL HQ. This is done as follows:

  1. Download and install ARRL’s Trusted QSL (TQSL) software.
  2. Run the program and create an automated certificate request, a .tq5 file. You do this by following the instructions that appear if you have not previously loaded a certificate, or by using File --> New Certificate Request. Answer a bunch of questions about your callsign, the “DXCC entity” for that callsign, the start date and optional end date for QSOs, your postal and email addresses, and optionally a password that will be needed to unlock the certificate each time you sign your log. You are then invited to sign your certificate request using a LoTW certificate you have previously obtained, or to submit an unsigned request. When you finally get to click the finish button, TQSL creates the actual certificate request file and offers to save it somewhere on your disk. It can go anywhere but pick somewhere obvious so you know where to look for it.
  3. Either upload the .tq5 file using the Upload Certificate Request button on the LoTW page or email it in as an attachment to ARRL HQ.
  4. Wait for ARRL to validate the request. If this is your first request, ARRL will check your name and address against the FCC records and post you a password to the registered address that you will need to enter into the Enter Postcard Password button on the LoTW page (if you are a US ham) or else will email you asking for a hardcopy of your license documentation and some other official document such as a passport or driver’s license to confirm your name. Post this to ARRL HQ by registered mail or courier to reduce the chances of it being stolen and used for identity theft.
  5. ARRL will email your new certificate to you as an attachment - it’s a .tq6 file.
  6. Load the new certificate into TQSL , either by double-clicking the email attachment [be very careful!  This is how viruses spread!] or by saving the attachment on your disk and then using File --> Load Certificate File in TQSL and locating where you just saved it.
  7. TQSL will attempt to match up the certificate with the corresponding certificate request. If it succeeds, the red circle and crossing bar will turn into a gold ribbon on TQSL’s display, meaning that your certificate is ready to use. If it fails, contact ARRL for help.
  8. Now make a backup copy of your certificate and other info in TQSL using File --> Backup Station Locations, Certificates, and Preferences ...

    TQSL backup

    Save the tqslconfig.tbk file to your favourite offline backup media (USB memory stick, CD/DVD ROM, floppy disk etc.) and store it somewhere safe. Then, if your hard drive dies, the computer is stolen or wrecked (e.g. by ransomware), or if you buy a new one, you will need this backup to restore your information on another machine - much easier than having to start the whole process again by requesting a new certificate, proving that you are duly licensed, then linking your new certificate to your existing LoTW and DXCC accounts.

You are nearly ready to digitally sign your ADIF-formatted log using the new certificate and submit it . .. but first you need to set up a “location” within TQSL:

  1. Run TQSL and select Station --> Add Location.
  2. Enter the required information including your locator, CQ zone, ITU zone and IOTA reference if you are on an island.

Here are the lucky 13 steps involved in extracting, signing and uploading your log from Logger32 to LoTW:

  1. Export your log from Logger32 as an ADIF file. Save it somewhere memorable on disk. [You can either export the entire log, or just the QSOs marked to go to LoTW. The former makes sure all QSOs will reach LoTW and is what you do the first time, and perhaps again every year just to be sure none are missing. The latter is quicker for subsequent updates.]
  2. Run TQSL . [See below for a shortcut for steps 2 through 9]
  3. In TQSL , go to File --> Sign existing ADIF or Cabrillo file.
  4. TQSL prompts you for the certificate (called "location") to use. Pick the correct one and OK it.
  5. Now TQSL prompts you to find the ADIF [or Cabrillo] log file.  Go to the directory where you saved the log, select and OK it.
  6. Next TQSL asks where to save the signed log (a .TQ8 file). I normally use the same directory as I used in steps 1 and 5.
  7. TQSL offers you the chance to sign a part of your log file between 2 dates. Normally, I just click OK with no dates in the boxes, for the whole thing.
  8. Enter your certificate password if prompted.
  9. TQSL then reads the QSOs from the input file, writes them to the .TQ8 output file and signs the result cryptographically using your certificate password, the certificate and a little crypoto magic . [This is necessary to prevent someone forging or altering your log.]
  10. Close TQSL. It's job is done until the next LoTW upload.
  11. Now login to the LoTW site at (click the LoTW User's Login button, then enter your LoTW user ID and password).
  12. In the LoTW site, click the Upload file tab, then find the .TQ8 file you saved at 6. Be sure to select the .TQ8 file, NOT the ADI file (LoTW will accept any file as input but can only process signed logs i.e. .TQ8 files. It won't warn you if you pick the wrong one, your QSOs just won't appear).
  13. Now wait a while for it to process your log. If the queue is busy and you have just uploaded tens of thousands of QSOs, it may take some while, perhaps an hour (I'm guessing). Normally, for a few tens of QSOs, they are processed before the next screen loads.
  14. Click the Your QSOs tab in LoTW, then check your log has been uploaded. It shows the last QSO date on that page, I think: I usually just click the Show latest QSL button to check if I have any new confirmations, especially those with ticks meaning lovely new DXCC confirmations  :-)

Now the remaining 9 steps to download the QSL records from LoTW to Logger32:

  1. On the Your QSOs tab, click the Download Report button on the left.
  2. Enter a starting date, or leave blank for all. LoTW seems to default to the last date you used the system - I normally go back a few days, and sometimes right back to the start of my log just to be sure I've captured all the LoTW QSLs. [I've noticed that LoTW seems to send all the QSLs anyway i.e. I'm not entirely convinced this starting date option works.]
  3. Check (select) the box marked Include QSL detail. The additional info is useful!
  4. Click the Download report button. LoTW then sends you an ADIF file with QSL info on all confirmed QSOs. The file downloads to your browser's default download location - I don't know where yours will go. You might have to go looking for it using Windows search, or check the browser configuration options. It is called lotwreport.adi (the first time) and lotwreport(1).adi next time, incrementing by one each time unless you delete previous downloads.
  5. In Logger32, select File --> Synchronise LoTW.
  6. Find the downloaded QSL file from step 4, and OK it.
  7. A selection box pops up, asking you what to do with QSL records that don't match existing QSO records. I normally select just the Manual update... option.
  8. Logger32 asks you about the LoTW mismatch file, just click Yes (muttering “Get on with it!”).
  9. Logger32 now opens the new QSL file and compares each QSL record to the corresponding QSO record. It prompts you to check and accept/reject different (normally additional) info in the QSL record, such as Maidenhead locators etc. You can accept most things but it refuses to accept some entries, mostly in my experience “PQ”, “NF” and “AK” plus locations such as “St. Louis” (which usually comes through from LoTW as SAINT LOUIS).

There’s more on LoTW here including tips on synchronising Logger32’s DXCC statistics with LoTW.

Back to quick links


Using Logger32 with the Elecraft K3

Logger32 will communicate quite happily with the Elecraft K3 and other radios via their serial ports. Elecraft radios emulate the Kenwood command set, but choose the right radio type to get the full range of commands. There’s a K2/K3 section in the Logger32 help file that tells you how to configure the radio comms.

There is a small drawback to the K3, for me anyway.  It defaults to the ”wrong” sideband for CW and digital modes when QSYd using Logger32. I prefer tuning from the bottom of the band upwards, hearing successive CW tones going high-to-low as I go, which requires CW-REV mode on the K3. That's fine, until I click on a spot in Logger32: as well as QSYing the rig for me, it automagically resets the radio mode to [normal] CW. :-(

A simple workaround nearly solves this annoyance. Simply tell Logger32 to use mode CW-R in place of CW in its band-mode table, and likewise use FSK-R instead of RTTY.  The table is accessed from the Tools menu (select "Setup Bands & Modes"). Open the table, find a CW entry, edit it to read CW -R and hit return to finish editing that line, then go to the next ... and finally click the Apply button. Now whenever you click a CW spot, the radio QSYs to the frequency and sets itself to CW-REV. The workaround doesn’t fix Logger32’s NCDXF beacon-tracker QSY function though, which still insists on putting the K3 in CW mode. Given that I only use it occasionally, I can live with that.

The contest logger N1MM+ has a setup option to use CW-REV. Easy.

Logger32 can send arbitrary command strings to the K3 through the ‘radio control panel’ function. I use this mostly to trigger the K3 to send my callsign from its DVK memories in DX pilesup, using a handy function key on the PC keyboard. There’s a config option that lets me use the function key  even while I am running some other program (such as when I am working in Word or Excel): the trick is to pick function keys that you rarely if ever use in any program, such as F6, F7 and F8 in my case. I have F6 configured to send the K3 “RX;” command which aborts sending the current message if I trigger it by mistake - tapping the rig’s PTT footswitch achieves the same end but first I have to duck under the desk to find where the footswitch is hiding ...

There’s more on the Elecraft rigs here.

Back to quick links

Hawke’s Bay
North Island
New Zealand

39o 39’ South x 176o 37’ East

Locator RF80HL

260m ASL


CQ zone 32

A1 Ops

DX CoC logo new 125 on black
Clublog logo 125
G QRP Club