Go home
Home
Station
Homebrew
TS850 mods
Antennas
Logger32
Interests
Contesting
Friends
QBL
Links
QSL!
Go home
Logger32

Quick links

Evaluating logging programs

A year or so ago, having moved to ZL and re-started my DXCC hunt with the new callsign, I decided this was the ideal opportunity to have a go at computerised logging. My pile of hardcopy G4iFB logbooks is 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.  These will be evaluation criteria. *
  • Next, I prioritised and ranked the requirements to generate “weightings” for each one. *
  • Put the above info into rows of a spreadsheet, adding columns for every logging program I could find.
  • 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 the requirements and weightings are personal. They reflect what’s important to me in how I intended to use logging software, and incorporate input from enthusiastic DXers on the CDXC mailing list.  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.

Published April 1 The evaluation spreadsheet is still QRV. I’ve just added an evaluation of Turbolog, thanks to Michael G7VJR, and updated the Logger32 eval to acknowledge the bugs noted below. If you use 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.

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 not unlikely ... although I have noticed differences in the way some program interpret the ADIF standard so it’s not entirely painless.

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. 

Logger32

Logger32 is a good program but, like all software, is not without its problems. Here are a few of the snags and bugs I’ve found so far:

  • There are serious bugs in Logger32’s logbook backup function . There is no automated/scheduled backup function and the manually-instigated backups don’t always work as expected (note the plural - there are two separate functions to create backups of the log files and config files! Why Logger32 backs up log and configuration files separately is anyone’s guess). Under some circumstances, the backup function seems to create a new ZIP file with today’s date but its contents are not the latest log files.  Also the backup function doesn’t properly check for previous backups and wipes the whole drive if you select the “delete files” option so be careful. Be very careful. I know I am not the only one to have fallen foul of this problem.
  • The process of updating LoTW is tediously manual (see below). Some other logger programs automate all of this apart from the user entering their password into TQSL to sign the log. AClog by N3FJP makes a particularly good job of it.
  • 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). Again, AClog allows this. There’s also a neat online LoTW log download utility by K1MU.
  • The QRZ.com lookup function only pulls up a subset of the information on QRZ and is not very configurable (e.g. there’s no obvious way to show QSL manager info, or display the entire QRZ page for the current call). My system has never, to my knowledge, populated the QSL via field of my logbook from QRZ.com. The lookup can’t cope very well with, for example, ZL/G4iFB: if there is no QRZ page for ZL/G4iFB, it should be intelligent enough to try G4iFB for me without me needing to edit the call in the lookup box.
  • The process for changing how the logbook looks is tedious and decidedly non-standard (cranky!).  Instead of simply being able to drag columns around on the logbook screen (standard behaviour for Microsoft and indeed most Windows programs), I have to enter a separate configuration screen, then carefully drag the relevant columns into the right sequence while avoiding crossing other columns already shown. This is tricky even for an able-bodied computer user but must be next to impossible for those with physical handicaps. 
  • There is a separate configuration menu that replaces the normal top line menu, adding a “main screen” button to close it. This is also non-standard.
  • Some menu items and options are not easy to find. The main way of accessing config options throughout Logger32 is to right-click in the relevant part, except ‘in the relevant part’ means not just anywhere in the log entry window, for example, but only on the data entry panels of the log entry window. The program won’t let me change the country for a QSO as I’m entering it (e.g. to put VK9ALH on Lord Howe Island, not Australia), only after it is entered in the log.
  • The logbook scroll buttons work more-or-less as expected (line up/page up/top/line down/page down/bottom) but the Windows default page-up/down action on clicking the scroll bar either side of the position indicator does not work ... probably because there is no ‘position indicator’. Yet another non -standard “feature” of this program. What’s wrong with the Windows defaults?
  • The program automatically erases incomplete log entries at the most inopportune moments e.g. when correcting the callsign for a QSO in progress. People make mistakes with calls and correct them: there is nothing wrong with that. The program should not delete entered reports, names, QTH info etc. just because I change the call. This is another bug.
  • Information about whether the current QSO is an all-time new country, a new band-slot or mode-slot, or needs to be confirmed, is easily overlooked in the lower status bar. There is no obvious way to determine this information while scrolling through previously-entered QSOs in the logbook, other than to troll painstakingly through the DXCC awards status screen. If there is some way to flag such special QSOs in the logbook, I can’t find it.
  • The program won’t let me select multiple QSOs to make bulk changes, e.g. to fill-in missing reports, change the QSL status etc. It insists that I do everything one QSO at a time. Again, I know this has been requested by other Logger32 users on the “support” forum but to no avail so far.
  • The “support” forum for Logger32 on Yahoo! groups is the most unfriendly I have ever experienced in any context. Most bug reports and improvement suggestions from users are simply dismissed out of hand and users are scolded for not reading the help file (which is good but doesn’t have all the answers) or ‘doing something wrong’ (i.e. wanting to do something that the support person doesn’t do and doesn’t agree with, regardless of the logic behind the request). We were recently berated for working VP6DX more than once simply because the support person hadn’t yet made any QSOs, and someone who asked about tracking Satellite DXCC received the comment “DXCC via repeater? Is this for real? Surely not.” These were not merely jokes but barbed comments from someone who is evidently out of touch with DXing.

There’s more on various Logger32 add-ons below.

CheckCall

CheckCall (download from the Hamlogger files area on Yahoo! groups) is a third party optional Logger32 add -on that looks-up any callsign as it is entered in the latest versions of Logger32 against a text file, then display all lines in the file matching the callsign. Useful to look-up things such as whether the callsign holder uses LoTW, belongs to CDXC or other clubs, has a QSL manager etc. [Note: it only works if properly installed but there are no installation instructions yet, apart from a brief explanation on the Hamlogger Yahoo! group.]

FrequencyManager

FrequencyManager is another third party optional Logger32 add-on from N2AMG, actually a separate memory program that interfaces to your rig via Logger32. It would be useful to store a list of beacons, for example, storing their frequencies, modes, callsigns, locations and other data from G3USF’s marvellous beacon list.  FrequencyManager can indeed store thousands of entries but only frequencies and callsigns, and they have to be entered manually since, although there is a data file, its format is not user friendly. In fact, there’s a prominent “Do not edit this file!” warning at the top! I’ve explained my requirement and requested an update from N2AMG ... no joy so far ...

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:

  1. 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.
  2. 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.

Anyway, here is a single sample of the finished article, showing the rear side of my QSL card to DR1A with 3 QSOs on one label (I picked three lines so a “full-house” of QSOs with one station on all nine HF bands will spread across three cards). You can just make out the top edge of the label. The images and other stuff are printed on the rear of the cards themselves:

Sample QSL card rear

I gave up trying to define the logic to print the specific antenna/s for each band and will have to do that bit manually on the card. Since I normally scribble a comment and signature anyway, that’s not a problem exactly, just another annoyance. Computers are supposed to reduce the drudgery!

The offset ‘QSL via’ bit used 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 a bit easier.

The ‘TNX QSL!’ bit becomes ‘PSE QSL for DXCC’ if I have not recorded receipt of a paper QSL in Logger32.  This particular example QSL shows another problem with LogPrint’s logic for multi-line QSLs like this one: I have a QSL for the earlier 40m QSO but not the later two. I could print a ‘QSL’ column with ‘PSE’ or ‘TNX’ against each QSO, I guess as there is just about enough space

The ‘73 CUL’ bit is followed by the person’s name if I recorded that in the log, using one of those optional “fields”. I guess I didn’t catch DR1A’s name in the contests! 

Spot the missing RST too: when importing the 2006 CQ WW CW log from N1MM to Logger32, I somehow omitted the RST field (grrrr).

If you like the layout of this card, here is my LogPrint.ini file containing the configuration info. Drop it into your LogPrint program directory under C:\Program files\LogPrint (in my case, anyway), after saving your own version in case mine doesn’t work for you. It’s just a text file, manually editable in Notepad or WordPad.

LogPrint is not brilliant at sorting QSLs. Sure, it has a sort function but can’t seem to integrate those “QSL via” contacts with a QSL manager in the proper sequence with the remaining non-QSL-manager ones. Doh!

Finally, there’s yet another gotcha when it comes to printing labels. 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. 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.

Good luck. You’ll need it, along with a lot of patience. Still, it beats hand-writing hundreds of cards.

VE7CC DXcluster software

VE7CC’s cluster user software is not part of Logger32 but works well with it. 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 bits are that it:

  • Automates the cluster reconnection/keepalive process, which is very handy on a marginal satellite broadband connection that drops-out when we have heavy showers
  • 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)
  • Indicates LoTW users by adding a plus to the text field on the relevant spots
  • Indicates the locations of spotted stations including US states - useful as I’m searching for North Dakota to complete the set for WAS

I think it will let me connect to multiple clusters to compare spots but I haven’t had a chance to play with that yet. It’s a neat utility anyway.

Using Logbook of The World with Logger32 Published April 9th

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.

First, 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 few months just to be sure none are missing. The latter is quicker for subsequent updates.]
  2. Run TQSL. 
  3. In TQSL, click the File menu, then select "Sign existing ADIF or Cabrillo file".
  4. 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.
  5. Now it will prompt 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 will prompt you for 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 TQSL password when prompted. TQSL then reads the QSOs from the input file, writes them to the .TQ8 output file and signs the result cryptographically using your TQSL password, the certificate and a little magic. [This is necessary to prevent someone forging or altering your log.]
  9. Close TQSL. It's job is done until the next LoTW upload.
  10. 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).
  11. 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 don't appear).
  12. 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.
  13. 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 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 (and mutter “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" and Alaskan locations plus "St. Louis" (usually comes down from LoTW as SAINT LOUIS). 

AClog, and probably other loggers, successfully automate practically all of this except the TQSL password entry bit.  Wouldn't it be nice if Logger32 did the same thing?

The only shortcut I’ve found is to include links to TQSL and the LoTW website on Logger32’s external programs menu. Whoop.