|
Quick links
- Evaluating logging programs using a structured software evaluation method
- Logger32’s features, snags and bugs - the highs and lows of an excellent logging program
- Check Call - L32 add-on displays relevant lines from text files when you work someone listed
- Frequency Manager and FreqPad - more Logger32 add-ons for rig memory management
- 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 your log to LoTW and downloading QSLs
- Using Logger32 with the Elecraft K3 - a few hints for Elecrafty users of Logger32
This page is mostly about computer logging with Logger32, plus related topics.
Evaluating logging programs
Having moved to ZL in 2005 and re-started my DXCC hunt with the new callsign, I decided this was
the ideal opportunity to start computerised logging. My pile of hardcopy G4iFB logbooks and
boxes of G4iFB QSLs are now 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 basic principles:
-
First, I determined my requirements and listed them out, taking suggestions from fellow
DXers in CDXC. These are the 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 rows of a spreadsheet, adding columns for every logging program I
could find and a column for the weightings.
-
Obtain evaluation copies of the logging programs and complete 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 weighting.
* Please note that both the criteria and weightings are personal. 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 may differ from mine, in which case you are very welcome
to download the spreadsheet and adapt the requirements and/or weightings to suit your purposes.
The evaluation spreadsheet is still QRV. If you use or evaluate any of the logging programs listed,
or indeed others, and are willing to share your scores and comments, 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 and weightings!
So far, I have chosen to use K4CY’s Logger32 for my everyday station log and (although I haven’t
yet 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 work out (which, reading the next section, is entirely possible)
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 reliable log backups first!
ADIF output is important too if you use ARRL’s Logbook of The World, which I would definitely
recommend (it’s one of the heavily-weighted criteria in the evaluation spreadsheet). The interface
to LoTW is somewhat clumsy and the initial registration process laborious but it’s worth it in the
end to have electronic confirmation 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.
Back to quick links
Logger32
Logger32 is an
excellent logging program
with loads of useful features such as:
- It’s
free,
as in free beer if 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 bug reports and
improvement requests from users.
-
It follows the
ADIF XML standard closely,
allowing me to exchange logs easily with other
ADIF-compliant programs such as N1MM and LoTW.
- It
competently handles the basics
- things such as entering and storing QSO information,
displaying country info, beam headings, times, previous QSOs etc.
- 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 (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, albeit the process to do so is a
little awkward. The logbook column headings can be customized by overtyping the labels in
the Setup --> Grid layout screen, though this is not obvious (there’s just a little hint in the
help file).
-
It’s extensible
with several useful third party add-ons released by other generous hams.
-
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.
- Another useful additional function gives
integrated access to MMTTY
combining QSO logging
in Logger32 with waterfall/Lissajous display, decoding, memory replays etc. from MMTTY.
The “Sound card data” function also lets me set up and send key macros (custom command
strings) to the K3 without having to drop out of Logger32 or at least close the control port in
order to run K3 Utility.
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):
-
The optional add-on to check QRZ pages
messes up the window focus
. For example, if I
put a call in the logbook callsign entry field without entering it but then click on the band/mode
entry for that country in the worked/confirmed window (e.g. to check if I have worked it
already this year), the focus jumps to the QRZ page instantly (it evidently does the QRZ
lookup then) and Logger32 hides the window showing previous QSOs with that country on
that band and mode. I have to click the band/mode entry again to see the data I wanted.
With MMTTY running in the sound card window, the changing focus when I enter a callsign
seriously messes up my attempts to type into the TX buffer in the same way. Very annoying.
The lookups are also rather slow on my machine, noticeably slower than they used to be with
the built-in L32 QRZ lookups.
-
There are
bugs in the logbook scrolling functions
: for reasons I still don’t understand, the
logbook scrolling doesn’t use the standard MS Windows scrolling functions, but a unique
implementation for Logger32. Sometimes the window jumps unexpectedly instead of
scrolling to the expected adjacent view (e.g. while checking through the log for new countries
to QSL after WPX RTTY contest, a single click in the page-up area took me up about 4,000
QSOs!). When the slider bar is near the bottom or top of its range, it is impossible to move
screen-down or screen-up respectively unless you can click in the vanishingly small space
between the slider bar and the line-down or line-up buttons.
-
The log entry panel
deletes entered reports
if I click on, say, the log window having entered
a callsign and reports into the log entry window but before saving the QSO. Previous versions
of Logger32 used to delete the QSO info if I changed the callsign before saving a QSO. Bob
said that it would delete default reports, but I’m not using the default reports at the moment
and yet it still deletes reports if I click elsewhere before saving a QSO. For some reason, this
bug only seems to affect the reports: it leaves other info such as name untouched. [Bug
reportedly fixed in the next release of L32 ...]
- The logbook can be
sorted
by several fields. The sort happens quickly but does not leave the
cursor and display on the prevously-selected QSO line right after the sort, which again should
be an MS Windows default. [For example, with the cursor sitting on a G3 QSO, if I sort the
log by callsign, it should finish up with me still looking at that G3 QSO but now in sorted
callsign order.]
- The manual process of
updating LoTW
(creating the log extract from Logger32, signing it,
uploading to the LoTW website, downloading the LoTW confirmations, importing them into
Logger32 and dealing with any differences between logged data and LoTW data) is tedious,
although there are some tips to make it a little more user-friendly (see below). [Some other
logging programs automate all of this apart perhaps from the user entering their password
into TQSL to sign the log, if needed. AClog by N3FJP makes a particularly good job of it.]
-
There are too many
unnecessary confirmation clicks
. For example, to recalculate DXCC
statistics, we have to open the 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. [It would be nice to
have the option to reduce the number of confirmation clicks.]
- Logger32 makes occasional
errors in the DXCC country allocation
e.g. HA1AR was
somehow identified in my log as DXCC country 230 (Germany) but is of course 239
(Hungary). Similarly with a French station labelled Swedish, TX3A on Chesterfield Island
labelled as Serbia (!) and others. This problem happens sporadically and could perhaps be due
to something I am doing when using Logger32 (like maybe correcting calls?). The errors
presumably mess up the DXCC tally and are not easy to find, though Clublog does a great job
of pointing out the anomalies at least. A separate DXCC validation function in Logger32 might
help.
- 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.
- Despite the log containing most of the information necessary, there is
no function in
Logger32 to create the paperwork for QSL card-based DXCC applications
. Recent
Logger32 changes to allow for QSLs to be identified as having been submitted and/or
validated for DXCC etc. may be useful but evidently require us to enter the corresponding
status information manually one-by-one. [A workaround involves exporting the log as an
ADIF file and uploading it into one of several other logging programs that handle DXCC and
awards tracking properly, such as DXkeeper or Clublog, and perhaps then re-importing it into
Logger32 but 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
‘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.
- The process for
changing the layout and content of the logbook window
is non-standard.
Instead of simply being able to drag columns around on the screen and hide/reveal them
(standard behaviour for Microsoft and indeed most other Windows programs), 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.
- The program 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 etc.
- 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: 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.
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: “From a programmer’s point of view, the user is a peripheral that types
when you issue a read request.”
Back to quick links
CheckCall
CheckCall from JA1NLX’s website 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. 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 can write and save 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!
Back to quick links
FrequencyManager & FreqPad
FrequencyManager is a Logger32 add-on from N2AMG. It stores frequencies and callsigns in an MS
Access database and interfaces to your rig via Logger32. It could be useful to store and scan a list
of beacons, for example. FrequencyManager can store thousands of entries but only stores the
frequencies and callsigns for each entry (no additional text notes, unfortunately). The program has
a function to import data from a
text file but the file format is user unfriendly, splitting each
memorised entry into two separate lines in the data file, joined by an initial number. An import also
wipes out anything stored previously, it seems.
FreqPad is a similar memory manager for Logger32 that handles up to 100 memories each
containing a frequency, mode and label. Unlike FrequencyManager however, FreqPad’s data file is a
simple text file and hence dead easy to set up or edit. To install FreqPad:
-
Download the FreqPad files from JA1NLX’s website
-
Open and unzip the files to your Logger32 directory (probably C:\Program files\Logger32\)
-
In Logger32, use Tools --> Utility program setup to add a utility program entry pointing to
FreqPad.exe
-
Click the new entry from the Logger32 Utilities menu
-
Ignore the error the first time you run it (!)
-
Click the FreqPad window
- Click File --> Open, then navigate to the Logger32 program directory and find the data file
FreqPad.txt, select it and hit Open
-
On the FreqPad window, right-click the blue frequency display: another window pops open
displaying the contents of the FreqPad.txt data file
-
Click any line in the file to QSY the radio there
-
Optionally in the FreqPad window, click Option --> Always on top so the window remains
visible after you’ve selected a frequency
I’m using FreqPad to memorise and recall details of the 10m beacons I’ve heard - you’re welcome
to download and use or modify my data file if it’s any use to you.
Back to quick links
Logprint
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
don’t)
-
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
know).
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
be defined:
- 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. My test file is here - feel free to download it and use or adapt it to your
own requirements, but don’t believe the contents!
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
comment:
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”.
If you like the layout of this label, here is my LogPrint.ini file containing the configuration info. Drop
it into your LogPrint program directory (C:\Program files\LogPrint usually), after backing up your
own version in case mine doesn’t work for you. It’s just a text file, manually editable in Notepad or
WordPad as well as via Logprint’s configuration screen.
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
cards.
Back to quick links
VE7CC DXcluster software
VE7CC’s cluster user software is not part of Logger32 but works well with it, or indeed with other
logging programs. It allows me to set up a local DXcluster on the station PC, pulling selected DX
data from the Web and presenting it to other programs, such as Logger32, as if they were
connecting directly to the cluster. The useful features that it adds are as follows:
-
Automates the cluster reconnection/keepalive process - no more manual reconnections
needed
-
Makes it easy to configure a bunch of spot filters e.g. by bands, modes, continents and even
times (there’s really not much point getting topband spots at local noon - well not normally)
-
Indicate LoTW users by adding a plus to the text field on the relevant spots using data from HB9BZA
-
Indicate the locations of spotted stations including US states - useful as I’m working towards
WAS
I think it will let me connect to multiple clusters to compare and collate spots but I haven’t had a
chance to play with that bit yet. It’s a neat free utility anyway. Thanks VE7CC!
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 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 from this SourceForge page for
Windows users [Linux and Mac versions are also available]. The download package actually
contains 2 programs:
TQSL
(used to sign your logs) and
TQSLcert
(used to request and
manage your digital certificates).
-
Run the TQSLcert
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
(see here). 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
TQSLcert
, 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 TQSLcert and locating where you just saved it.
-
TQSLcert
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 TQSLcert’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
TQSLcert 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:
- Run
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.]
- Run
TQSL
. [See below for a shortcut for steps 2 through 9]
- In
TQSL, go to File --> Sign existing ADIF or Cabrillo file.
- TQSL
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.
- 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.
- 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.
- 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.
-
Enter your certificate password if prompted.
- 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.]
-
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
appear).
-
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
confirmations :-)
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
downloads.
-
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).
Semi-automating LoTW updates in Logger32
AClog, and probably other loggers, successfully automate much of the above process except for
the TQSLcert certificate management and TQSL password entry bits.
Wouldn't it be nice if
Logger32 did the same thing?
Well the log-to-LoTW bit
can
be partially automated by using the
appropriate command line parameters when running tQSL. The trick is to define tQSL as a “utility”
program in Logger32. This is achieved using the Tools --> Utility program setup option. On a
blank line in the table, add a new util menu item “tQSL”. Under the util program and parameters
column, enter the following command:
C:\Program Files\TrustedQSL\tqsl.exe -l ”Castle Peak” -d c:\Download\LoTW out.ADI -x
That’s the command line from my machine. You will need to customise yours a bit:
-
The first part includes the directory where you installed the Trusted QSL program from ARRL.
-
The -l (that’s a lowercase L) switch means what follows is a “location” that tells tQSL which
digital certificate to use. If I run tQSL normally from the icon, it offers me just one “location”,
namely “ZL2IFB - Castle Peak” (Castle Peak is the name of the house I’m living in, and is the
“location” I use). Yours will be different. If you location has only one word, you can omit the
quote marks around it.
-
The -d switch says “Don’t ask me for a date range”. Since Logger32 normally only outputs
log entries that have been marked for LoTW upload, there is no need to specify dates.
-
The input file name follows. I normally save all my LoTW output, plus the signed log files and
downloaded LoTW QSL info, in the same directory i.e. C:\Download. Yours could be
anywhere on your disk. It helps to be consistent.
-
The final -x switch tells tQSL to exit immediately after it has signed your log, leaving you
ready to upload the signed log file (normally a .TQ8 file) to LoTW. Go back to step 10 above
to finish the process.
After running tQSL with this command line, you will still need to enter your password to unlock the
certificate and make sure some naughty hacker isn’t signing your log (!) ... unless you remove the
password using the instructions here. Using the utility program as specified here makes uploading
to LoTW simpler and hence it’s worth uploading more often, perhaps weekly or even daily.
Remember, if you lose your local log for some reason (hard disk failure, operator error, lightning
strike, fire, theft ...), LoTW will still retain the vital details up to the latest update, but you will lose all
your notes, paper QSL records etc.
I’ve added a shortcut to the LoTW website too, as another “utility” entry. The command is
something like:
C:\Program Files\Mozilla Firefox\firefox http://www.arrl.org/lotw
... only it depends where your browser program is located and which browser you use, and you
can start with whichever web page/URL you like. Go ahead, try it for yourself!
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 presumably K2) radios via their
serial ports as they mostly emulate the Kenwood command set. 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 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 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 solves this annoying problem. Simply tell Logger32 to use mode CW-R in
place of CW in its band-mode table. [The table is accessed from the Tools menu pull-down (select
"Setup Bands & Modes"). Open the table, find a CW entry, edit it to read CW-R and hit return to
finish editing each one, then the next ... and finally click the Apply button. Now when you click a
CW spot, the radio QSYs to the frequency and sets itself to CW-REV. Easy peasy :-)]
N1MM has the same problem: clicking a CW spot on the band changes the K3’s mode to CW, with
no obvious way to choose CW-REV. [Workaround: configure N1MM to use a fixed mode of CW
-REV - it’s in one of the config menus, sorry I forget where. Don’t forget to reset it for a SSB, data
or mixed mode contest!!]
Logger32 will also trigger replay of the K3’s DVR voice memories, sending commands through the
serial port using it’s DVK function.
There’s more on the Elecraft rigs here.
Back to quick links
|
