- Evaluating logging programs using a structured software evaluation method
- Logger32’s features, snags and bugs - the highs and lows of an excellent logging program
- HamQTH lookups - using Logger32’s built in function
- MMVARI - soundcard data software integrates with Logger32
- Check Call - L32 add-on displays relevant lines from text files when you work someone listed
- Logger32 hack: identify arbitrary calls - ‘repurpose’ Logger32’s LoTW lookup function
- LogPrint - user notes on the Logger32 add-on for printing QSL labels
- VE7CC local cluster software - run your own private mini-cluster locally on your PC
- Using Logger32 with LoTW - uploading QSOs to LoTW, downloading QSLs and DXCC records
- 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 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 still available, although out of date. If you use or evaluate any of the
logging programs listed, or indeed others, and are willing to share your scores and comments by
updating the spreadsheet, please let me know. All inputs are welcome, and I’m especially keen to
hear about logging programs that you feel score better than Logger32, preferably using my criteria
I have chosen to use K4CY’s Logger32 for my everyday station log and (although I haven’t gone
through a similar structured evaluation for contest loggers) 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 means I can 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.
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 date and time, callsigns (both the DX and you, as operator), band and
mode are all correct.
ADIF 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 award (if you enjoy collecting prefixes that is - it’s a bit too close to train spotting or car
number plate spotting for my liking, and I don’t wear an anorak).
Back to quick links
Logger32 is an
excellent logging program
with loads of useful features such as:
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 ask for nothing in return. Kudos to them
for their true amateur spirit and for responding positively to reproducible bug reports and
improvement requests from users (some, at least: they have their priorities too!).
It follows the latest
ADIF XML standard closely,
allowing me to exchange logs easily with
other ADIF-compliant programs such as N1MM and LoTW.
competently handles the basics
- things such as entering and storing QSO information,
displaying country info, beam headings, times, previous QSOs etc. Recent changes in the way
Internet call lookups are handled have made the process of logging QSOs much slicker so
Logger32 is now fast enough to keep up with me, even in pileup situations.
can be customized to show windows such as the logbook, DXcluster,
greyline map, log entry screen, notes and more, all on the one screen (the screenshot above
shows how mine looks today). The layout, sequence and colouring of most windows and the
highlighting to show DXCC and QSL status can be customized.
- It tracks
DXCC status well,
including a function to identify
‘in-year’ DXCC stats (i.e. DXCC
countries worked during the
current calendar year) which
also changes the filtering of
DXcluster spots accordingly.
This is ideal for the CQ
Marathon and annual league
tables such as those in Clublog.
See the screenshot -->
with several useful third party add-ons
written and released by other
talented and generous hams.
It has additional features such
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 new ‘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]
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).
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):
Pointless confirmation clicks
are annoying, especially in the program functions that I use
daily (e.g. LoTW updates through the otherwise very useful Logger32-LoTW/eQSL/Clublog
upload/download automation utility from N2AMG). To recalculate DXCC statistics, we have
to open the relevant menu to find the option, click it to pull up the recalc window (which does
nothing), and then click yet again to start the recalc running. There are several other places in
Logger32 where it 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 another click!
If 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? 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!
The logbook can be
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.]
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]
There is no simple way to create an ADIF file listing DXCC countries confirmed by QSL card
but not by LoTW, for
online DXCC applications
. [A workaround involves exporting the log
as an ADIF file and processing it through another program that handles DXCC and awards
tracking well, such as DXkeeper, and if necessary then re-importing the updated log into
Logger32 but given the choice I’d prefer to stick with Logger32 for the whole process.]
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
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.
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.
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.
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 the beacons are 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 once per day when the NCDXF beacon
window first opens.
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.
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 seen by the program’s
author: “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 QRZ.com
The built-in function works nicely with HamQTH.com. To set it up:
- Visit www.HamQTH.com and register. Preferably while you are there, lookup and
check/update the info page for your own callsign/s.
In Logger32, go to Setup > Autolookup and select Auto Internet Callsign Lookup (internal).
Start entering a QSO in the log entry window in order to pop up the lookup results window.
- On the lookup results window, go to Toolbox > Change
lookup URL (as shown here). Insert the relevant URL in
where your_callsign and your_password are your login
credentials for HamQTH.com.
Optionally, also on the lookup results window, go to
Toolbox > Change Window caption and enter HamQTH.
I prefer HamQTH to QRZ.com lookups for three reasons: HamQTH is generally quicker, it doesn’t
involve installing and configuring an external Logger32 utility, and most of all it is
FREE (HamQTH is
supported by advertising income and donations from happy users, whereas QRZ also receives
advertising income and donations but charges for XML lookups, unless you settle for slow HTTP
Back to quick links
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 modes.
The cool MultiRX feature simultaneously decodes multiple signals within the audio passband, in
much the same way as DigiPan.
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 so
you can 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 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
CheckCall from JA1NLX is a Logger32 add-on that looks
-up any callsign as it is entered into Logger32 against lists
stored on your PC as simple text files, then displays all
lines in the files matching the callsign in a pop-up box as
shown here. It’s useful to look-up things such as whether
the callsign holder uses LoTW, belongs to CDXC, FOC or other clubs, has a QSL manager etc. provided you provide
a text file containing the relevant details (callsigns plus any
notes). Follow the “ReamMe.TXT” (sic) installation
instructions provided in the ZIP file to install it. The
program allows lookups against more than one text file
simultaneously, saving the bother of having to merge the data files.
We can run CheckCall (or indeed any other utility program) automatically when Logger32 starts
simply by putting a tick in the box against the program in the “utility program setup” screen. Cool!
[It is also possible to get Logger32 to identify spots for FOC members - instructions below.]
Back to quick links
Logger32 hack: identify an arbitrary list of calls
Logger32 now includes a built-in function to check whether calls spotted and logged are using
LoTW. It does this by downloading the LoTW user file from HB9BZA, 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, and (when I remember) I put “LOTW” in the QSL VIA
field. 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
When I run the “Import LoTW
users” function in Logger32, it
saves 4 files in the Logger32
program directory (though it
should really use a separate
data directory): LoTWUsers.txt,
.isf and LoTWUser32.ism. The
latter 3 files appear to be
database files in which Logger32
saves its lookup info.
LoTWUsers.txt is a plain text file
of calls, as downloaded from
HB9BZA. 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 it uses to download
the LoTW users file from HB9BZA’s website.
So, here is the method step-by-step:
- Generate 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:).
In Logger32, right-click in the main body of the DX
Spots window, select Setup --> Load LoTW users file.
In the Download LoTW users file window that appears
(see right), replace the URL on the top line with file://C:/Logger32/FOC.txt (yes those are forward
slashes because it is a URL. If you saved the data file
in a different directory, good luck figuring out the
syntax for the URL!).
Click "Download from Internet" to make Logger32
suck-in the FOC.txt file, thinking it has just
downloaded the LoTW users file from HB9BZA.
Click "Save file" for Logger32 to save the FOC calls to its internal LoTW user database.
- Make 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.
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 - like
me - 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'. You can turn off Logger32's new-ones spot filtering if you like though. Even if you
don’t, Logger32 will still show the tick when logging any FOC member.
[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 comma-separated list of calls. I use this facility to flag stations
known to be in CQ Zone 2.
Back to quick links
The optional Logger32 add-on program LogPrint has some potentially useful functions:
Print QSL labels for QSOs marked “send paper QSL” in the log - that’s what I need right now
Output the log in HTML format (enabling me to put my log on the Web if I wanted to, which I
Draw a map showing the location of stations I’ve worked (must explore that idea further,
although I see that it draws straight lines from point to point, not great circle arcs)
Print out the log like a logbook (though why anyone would want to do that, I don’t really
Creating the templates for QSL labels is a tedious process that took me most of an afternoon, but
once completed it’s a breeze to print labels and complete QSLs. There are two things that need to
- The size of the label sheet and the individual labels. A reasonable range of Avery label sizes
are included in the program but naturally the labels I bought (2 columns of 8 labels per column
on an A4 sheet, with no margins) are not on the list. I had to convert all sizes into inches and
fractional inches since it is an American program, and guess at some of the parameters (e.g.
the selection between landscape and portrait refers to the label SHEET not the labels
themselves). Not too hard.
- The layout of the text and images on the labels. More on this below.
Laying out the labels is the most frustrating part of the process due to the program’s curious
interface. It is an old-fashioned parameter-driven setup, definitely not drag-n-drop WYSIWYG
(rather like the annoying method used to change columns displayed in Logger32’s logbook and
other windows which does use a finicky version of drag-n-drop but only in the parameter file, not
on the log screen!).
K5LAD has a helpful web page showing how the “fields” are defined.
Up to 15 “fields” can be defined, each consisting of any combination of the contents of ADIF fields
from the logbook, fixed text and optional text (printed if an ADIF log field is equal or not equal to an
arbitrary string). Each “field” can be positioned anywhere on the label (in inches, of course) but
expect difficulties if you mix fonts and font sizes as the positioning varies, making it awkward to
align “fields” with different settings (e.g. in my case, “QSO with” in 11 point black Arial next to
ADIF:Call in 16 point red Arial bold - the vertical settings need to be offset to line up on paper).
The ‘preview’ function that pulls up a print preview is useful although it does not update
automatically - you have to change a parameter, save it, then click the ‘preview’ button each time
to see the results of your efforts. It also needs an input file of QSL info: it doesn’t default to
anything useful such as a sample QSL info file, nor will it even display the fixed text ignoring the
missing ADIF fields.
I soon tired of waiting for the preview function to format and display a list of labels for 160-odd
QSLs waiting to be printed. What’s worse, the print preview function only displays the first sheet of
labels, meaning that if the first set of QSLs don’t have all the options you wish to layout, there is no
way to move forward to later sheets. I ended up manually creating a test ADIF file of QSLs, in my
case a subset of QSOs based on the real QSL file and adapted to include, for example, different
times, dates, bands and modes, multiple QSOs with the same station (for printing multi-line labels)
and ‘QSL via’ on some.
While configuring the labels I discovered an annoying bug in the LogPrint program: if I select “Not
equal to” but do not define the value of an ADIF field for the program to compare against (which
should mean an empty or undefined field, I think), it lets me save the field definition but then
crashes when I try to go back in and re-define the field. None of the ‘clear settings’ options
seemed to solve this problem. Even re-installing the LogPrint program didn’t seem to clear it (I
was somewhat reluctant to uninstall and delete all the LogPrint files and start from scratch, having
spent a few hours painstakingly defining sheets and labels!). I eventually managed to figure out a
workaround by manually editing the LogPrint.ini file: the field definitions are about half way down
the .ini, and it’s simple to change the “NotEqual” to “Equal”.
The next problem was a limitation of the program on the number and complexity of optional fields.
I’d like to have the program print out “160m inv-vee” for 160m QSOs, “80m inv-vee or vertical”
for 80m QSOs and so forth. Since each definition uses up one of those 15 “fields”, I soon run out
of “fields” before all my antennas are defined, not least because the tribander requires separate
“fields” for each band. What I really need is the ability to define a simple look-up table (bands vs.
antennas) or slightly more complex logic in the “field” definition selection criteria (e.g. IF (x AND y)
OR z THEN ...). Admittedly, I could define antennas in the ADIF file manually on each QSO but
unfortunately I can’t find a way to make Logger32 simply record a default antenna for the band on
each QSO, and in practice it is too tedious & slow to record the antennas manually.
I am toying with the idea of injecting SQL commands into the field definitions ... has anyone tried
that? I’d need to guess at the names of the tables etc. but it’s possible.
Another limitation is on the fixed positioning of variable length text (ADIF fields). It would have
been useful to have the ability to left, centre or right justify the text but no such luck.
Finally, it’s time to print some sample sheets and check the layout against the label positions. I’d
recommend printing on plain paper, not expensive sheets of labels, until it is about right as there is
a lot of to-and-fro, adjusting things by a few hundredths of an inch at a time. Holding the printed
sheet up to the light with a blank label sheet on top shows whether the printing matches the label
outlines. The is where I discovered that our laser printer leaves a margin, requiring some further
adjustment to the positioning. The “top margin” setting is really not enough - I needed to be able
to define margins on all sides (to the left of the left column, to the right of the right column etc.).
In the end, I settled for a blank margin all around every label.
There is no opportunity in the print dialogue to enter printer options such as “I’m using labels”. Our
laser printer handles sticky labels more slowly than plain paper to avoid the labels lifting. I can’t
select this at print time in LogPrint but a workaround is to set the printer default to labels
beforehand, and reset it to plain paper after the labels are printed.
On the main screen, LogPrint has options to sort the QSLs: it’s handy to sort them in the order
needed by the QSL bureau, which is an alphanumeric sort by the callsign of the station worked.
However, cards for stations with a QSL manager need to be sorted by the QSL manager’s call, not
the DX call: to do this, in the label file sort options dialogue, select QSL_VIA as the primary sort,
then CALL as the secondary sort.
Anyway, here is a single sample of the finished article, showing the rear side of my QSL card to
Brad. You can just make out the edge of the label. The grey text is printed on the rear of the card
leaving enough space for another label or, usually, a little hand-written thank you note or
With up to three QSOs per label, I can squeeze 6 QSOs onto each card.
I gave up trying to define the logic to print the specific antenna/s for each band and have to do that
bit manually on the card
The offset ‘QSL via’ bit uses up two precious 15 “fields” to get the words positioned just right but
leaves plenty of space either side for long calls. I deliberately put the station and QSL manager
calls in big, bold, red print to make the QSL bureaux’ task just a bit easier.
The ‘CUL’ bit is normally followed by the person’s name if I recorded that in the log, using one of
those optional “fields”.
Finally, there’s yet another gotcha when it comes to printing labels from Logprint. If, for example,
your printer mis-feeds one of the label sheets (quite a common occurrence), there is no way to tell
the program to reprint only a certain page of the output, or to skip the first N pages. It is possible
to replace the correctly printed page/s of labels with ordinary paper but mixing labels and ordinary
paper doesn’t help the mis-feed issue and wastes paper.
Good luck. You’ll need it, along with a lot of patience. Still, it sure beats hand-writing thousands of
Back to quick links
Using Logger32 with Logbook of The World
ARRL’s LoTW has been designed as 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, though why anyone would be foolish enough to make false DXCC claims is
beyond me (who are you kidding?). Anyway, the point is that logs cannot simply be uploaded to
LoTW as plain ADIF files: they must first be electronically 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:
Download and install ARRL’s “Trusted QSL” TQSL software.
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. Now you 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, TQSLcert 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.
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.
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.
ARRL will email your new certificate to you as an attachment - it’s a .tq6 file.
Load the new certificate into
, 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 TQSLt and locating where you just saved it.
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.
Now make a backup copy of your certificate in
TQSL using Certificate --> Save. This will
create a .p12 file. Save it to your favourite offline backup media (USB memory stick,
CD/DVD ROM, floppy disk etc.) and store it somewhere safe. If your hard drive dies, the
computer is stolen or wrecked, or if you buy a new one, you will need this .p12 file to reload
your certificate on another machine.
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:
TQSL and select Station --> Add Location.
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:
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 few
months just to be sure none are missing. The latter is quicker for subsequent updates.]
. [See below for a shortcut for steps 2 through 9]
TQSL, go to File --> Sign existing ADIF or Cabrillo file.
prompts you for the certificate (called "location") to use. Pick the correct one
(probably the only one but unfortunately not the default!) and OK it.
prompts you to find the ADIF [or Cabrillo] log file. Go to the directory where you
saved the log, select and OK it.
asks where to save the signed log (a .TQ8 file). I normally use the same
directory as I used in steps 1 and 5.
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.
Enter your certificate password if prompted.
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.]
Close TQSL. It's job is done until the next LoTW upload.
Now login to the LoTW site at www.arrl.org/lotw (click the LoTW User's Login button, then
enter your LoTW user ID and password).
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
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.
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
Now the remaining 9 steps to
download the QSL records
from LoTW to Logger32:
- On the Your QSOs tab, click the Download Report button on the left.
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.]
Check (select) the box marked Include QSL detail.
The additional info is useful!
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
In Logger32, select File --> Synchronise LoTW.
Find the downloaded QSL file from step 4, and OK it.
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.
Logger32 asks you about the LoTW mismatch file, just click Yes (and mutter “Get on with it!
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” locations plus “St.
Louis” (which usually comes down from LoTW as SAINT LOUIS).
Automating LoTW uploads in Logger32
A Logger32 add-on utility from Rick N2AMG lets us upload our QSOs to LoTW, eQSL and Club Log.
The LoTW uploads are done in batches by clicking the upload button and a bunch more
confirmations: I hope to persuade Bob/Rick to make this a fully automated process in due course.
There’s more on LoTW here.
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 mostly 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, namely that it defaults to the ”wrong”
sideband for CW and digital modes when QSYd using Logger32. Normally 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 or DATA-REV 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 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 the NCDXF beacon tracker’s QSY function though, which still
insists on putting the K3 in CW mode. For the very few times I use it, I can live with that.
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