Managing LoTW Locations in TQSL

My (overly) fastidious approach to logging my ham radio contacts has been well-documented. Since I upload all of my contacts to the Logbook of the World (LoTW), I like to reflect my locations accurately in the TQSL software. When you do most of your operating while portable, that can add up to a lot of locations to deal with. I’ll show you my approach to dealing with locations in TQSL. 

How It Started

As best I can recall, I started using LoTW about six or seven years ago. I started creating new locations in TQSL for every place I operated away from home. So, there were lots of campgrounds that my (far) better half and I frequented, along with an assortment of parks and other places my radio has been to. Then, along came National Parks on the Air, followed by Parks on the Air. Before I knew it, I was scrolling through a long list of locations to find the one I wanted for an upload to LoTW.

One approach to paring down the list, I suppose, would be to go in and delete the one-off locations I’m not likely to visit again. That, however, conflicts with my inherent packrat nature. (That also explains the boxes of assorted leftover screws I have in the basement.) 

One thing I noticed is that many locations in my list shared the same attributes, e.g.: state, county, grid square, etc. For example, all the parks in northern Delaware I activated recently are all in the same county and grid square. (Fun fact: Delaware only has three counties.) Based on this observation, I came up with an approach to tame my locations list and make it easier to scan the list to find a particular location.

My Location Naming Convention

I ended up deleting most of my locations is TQSL and created some new ones using the following naming convention:

STATE_COUNTY_GRID

The STATE is just the standard two-character abbreviation. The GRID is the four-character grid square. Here are some examples from my locations list:

DE_NewCastle_FM29
MD_Cecil_FM29
PA_Chester_FN20
PA_Chester_FM29
PA_Delaware_FM29

TQSL automatically stores the locations alphabetically, so it’s easy to scroll through the list to find the location I’m looking for. I kept one or two of specifically named locations for frequently used places like “Home.”

My "Station Locations" pane in TQSL showing some of the locations I have stored
My “Station Locations” pane in TQSL showing some of the locations I have stored

While this works for my situation here in the States, operations in other countries would likely need some tailoring. I’ll cross that bridge when I get to it. Also, if you have certificates for more than one callsign, you’ll need to account for that.

Where Am I, Anyway?

To use this approach, I need to know what county and grid square I’m in. There are a couple of resources I use to do that. Before I get on the air from a portable location, I use these resources on my Android phone:

  • What County am I In. When I access this website from my cell phone, it shows the county I’m in, along with the zip code, address, and coordinates.
  • Easy QTH Locator. When you launch this app, it uses your phone’s location services to show your grid square, along with your coordinates and elevation.

Once I have determined the county and grid square I’m in, I jot this information down in my notebook or take screenshots from the apps on my phone.

These are the resources I use, but a web search will yield lots of similar tools you can use. I should also note that I have no financial interest in these apps.

Wrapping Up

This could very well be another case of over-thinking on my part. Regardless, I’ve been using this approach for a while now, and it has been working out for me. I’d be interested in hearing your method of managing portable locations for LoTW.

Oh, and before I forget… Remember to make regular backups of your TQSL locations, certificates, and preferences. Someday you’ll be glad you did.

73, Craig WB3GCK

Adding Custom Fields to an ADIF File

I’m not much of a programmer. I’ll be the first to admit that. But, now and then, I manage to cobble together a useful script using the Python programming language to make short work of repetitive, tedious tasks. Here’s an example.

I described my process for logging contacts in a previous post. Part of that process is keeping track of where I was at the time and what rig I was using. My main log in N3FJP’s ACLog uses the other fields feature to implement the ADIF tags, MY_QTH and MY_RIG. Adding that information to ADIF files being imported into my main logging program was time-consuming.

I had been using ADIF Master to add these fields and populate them. I still highly recommend ADIF Master but I wanted to see if I could automate things using Python.

What I ended up with is a script that prompts me to enter my location and rig. If the ADIF file doesn’t already include a tag for TX_PWR, the script prompts me to enter my transmit power also. It then generates these new tags and inserts them in each record in the file. It takes me about 15 seconds to execute the script.

As I noted earlier, I’m no programmer. So, this code might not be the most elegant—or “Pythonic,” as they say—way to approach the problem. However, it does exactly what I needed.


Source Code

__author__ = "Craig LaBarge WB3GCK"
__email__ = "wb3gck at arrl.net"
__contact__ = "https://wb3gck.com/contact/"
__date__ = "5/03/2019"
__version__ = "v1.1.0"

# This script is used to add my custom tags to ADIFs exported from SKCCLogger or other programs.
# The script expects:
#     Files in ADIF located in the same working directory as the script
#     ADIF files must have a ".adi" or ".adif" extension.


import os
import sys


def listfiles():
    """This function finds all ADIF files in the working directory and prints out a listing with index
    numbers.  It returns a list of available ADIF files."""
    logs = []
    count = 1
    for filename in (os.listdir('.')):
        if '.adi' in filename:
            logs.append(filename)
            print(str(count) + ' - ' + filename)
            count = count + 1
    if not logs:   # Check for empty list; e.g., no PDFs found
        print('')
        print('Ooops! No ADIF files found!!  \nTerminating script...\n')
        sys.exit()
    else:
        print('')
        return logs


print('\n*** add_tags.py ' + __version__ + ' by WB3GCK ***\n')


# Prompt the user for the integer number corresponding to the desired message file.
# Check to make sure the input is within the proper range
good_file = False
file_choice = ''
file_list = listfiles()  # Get a list of ADIF files
file_in = ''
while not good_file:
    file_in = input('Enter the ADIF file number:  ')
    if not file_in.isdecimal():  # Check for non-numeric input
        print('Input must be a numeral!  Try again, Pal!')
        continue
    else:
        file_nr = int(file_in) - 1
    if file_nr < 0 or file_nr > (len(file_list) - 1):  # Check for out of range input
        print('Input out of range.  Better try that again, Bucko.')
    else:
        file_choice = file_list[file_nr]  # Sets the selected file name
        good_file = True

# Check the selected file for the presence of a TX_PWR tag
if ('TX_PWR' in open(file_choice).read()) or ('tx_pwr' in open(file_choice).read()):
    has_pwr = True
else:
    has_pwr = False

# Prompt user for the MY_QTH value
my_qth = input(r'Enter QTH:  ')
qth_tag = '<MY_QTH:' + str(len(my_qth)) + '>' + my_qth + ' '

# Prompt user for MY_RIG value
my_rig = input(r'Enter Rig:  ')
rig_tag = '<MY_RIG:' + str(len(my_rig)) + '>' + my_rig + ' '


# Prompt user for TX_PWR if there is no TX_PWR in the selected file
good_pwr = False
tx_pwr = ''
pwr_tag = ''
if not has_pwr:
    while not good_pwr:
        tx_pwr = input('Enter TX_PWR:  ')
        # Check for numerals and decimal points only
        try:
            val = float(tx_pwr)
            good_pwr = True
        except ValueError:
            print("Hey Bucko! Numerals and decimal points only!!")
    pwr_tag = '<TX_PWR:' + str(len(tx_pwr)) + '>' + tx_pwr + ' '

# Create the replacement tag
if not has_pwr:
    new_tags = qth_tag + rig_tag + pwr_tag + '<EOR>'
else:
    new_tags = qth_tag + rig_tag + '<EOR>'

# Modify the selected ADIF file
file = open(file_choice, 'r')
filedata = file.read()

# Replace the target string
if '<EOR>' in open(file_choice).read():
    filedata = filedata.replace('<EOR>', new_tags)
elif '<eor>' in open(file_choice).read():
    filedata = filedata.replace('<eor>', new_tags)
else:
    print('Are you sure this is a valid ADIF file?? \nTerminating script...')
    sys.exit()

file = open(file_choice, 'w')
file.write(filedata)

print('\nGreat success! ' + file_choice + ' modified.\n')

How to Run It

I run this script on a Windows machine, so this section is focused on that operating system. For Linux and Mac, you might need to do some research.

  • Make sure you have Python 3 installed on your computer. If not, you can get it for free at python.org.
  • Download the script file here and unzip it.
  • Place the ADIF file you want to modify in the same folder as the script file. 
  • Open a command window and navigate to the directory containing the script and ADIF file.
  • Start the script with the command: python add_tags.py. I use a Windows batch file to save having to save some typing. Depending on how Python is installed on your system, you might be able to just double-click the script file.
  • Following the prompts, enter the necessary information. That’s all there is to it.
Screenshot of the add_tag.py script running
Screenshot of the add_tag.py script running

Some Precautions

  • This script doesn’t check to see if you have already modified the ADIF file. If you have, you’ll end up with redundant fields in your ADIF file. Your logging program probably won’t like that.
  • Always keep a backup of your ADIF file or have an easy way to regenerate it. If you make a mistake in one of your inputs, just start over with another copy of the ADIF file.
  • I’ve only included a minimal amount of error checking in the script, so it’s far from bullet-proof. Double-check each input carefully before pressing <ENTER>.

Disclaimers

Of course, no article on software is complete without a disclaimer or two.

  • Use this script at your own risk. It works for me, but I make no guarantees that it will work for you.
  • I can’t offer any technical support or tailor it to your application.

So there you have it. If you find yourself having to routinely add fields to an ADIF file—maybe not, but you never know—feel free to modify this script to suit your needs. It should be easy to adapt it to add other ADIF tags.

If you want to dabble in Python programming, Google is your friend. There are tons of resources out there for learning Python.

73, Craig WB3GCK

My Favorite Apps for Portable Operating

I do the majority of my HF operating while out at portable locations. Like most people these days, I always have my cell phone handy. While I have a bunch of apps installed, there are a few that I use most often to figure out where to go and where I am.

Before I begin, I should mention that I use an Android phone. Some of these apps may be available for the iPhone or there may be similar apps available for you.

I should also point out that I do most of my hiking and biking on well-established trails. Suburban Philadelphia is not exactly a wilderness area. Wilderness and backcountry folks will likely have different needs.

Having said all that, here are the non-ham-specific Android apps I use most often in the field.

Where Am I?

This appropriately-named app by Ejelta LLC does exactly what it says. Using your phone’s location services, it shows where you are in the world. It shows your city, zip code, phone area code, sunrise and sunset times, elevation, and GPS coordinates. It also identifies the county you’re in, which is useful for setting up a new location in the TQSL software for Logbook of the World (LoTW).

Where Am I? Screenshot
Where Am I? Screenshot

The sharing feature is also important to me. When I’m out alone, I use Where Am I? to text my location to my (far) better half. I can send her the location of where I parked my truck and where I stopped along the trail to play radio.

Maidenhead Grid Locator

Another piece of information I need for LoTW is the grid square I’m in. For years, I used (and still use) an app with the simple title, Locator. As I started writing this post, I found that this particular app is no longer available in Google Play. No worries; there are lots of other apps to determine your Maidenhead grid square. Here are a few:

  • Ham Locator (by OH5GQF) shows your grid square (6 characters) on a map. You can toggle between street view and satellite view.
  • If you use HamLog (from Pignology) for portable logging, check the “Tools” tab. There’s a grid locator tool there. You can navigate around a map to find the grid square anywhere on earth.
  • HamGPS (by EA4EOZ) is a grid locator on steroids. It shows your current grid square out to 10 characters, along with your coordinates and compass heading. It also shows the location and status of the GPS satellite constellation. That can be fascinating to watch.

Ham Locator Screenshot
Ham Locator Screenshot

TrailLink and AllTrails

These are two similar apps that I use for planning trips to new trails. The Rails to Trails Conservancy produces TrailLink, while AllTrails is from AllTrails, Inc. They both give you maps, directions, reviews, and more. Both apps have paid versions that will let you save maps to your phone. That’s handy if you are in an area with poor cellular coverage.

AllTrails map display. You can zoom in and navigate around the map to see a detailed view. With the paid version, you can save maps to your device for offline use.
AllTrails map display. You can zoom in and navigate around the map to see a detailed view. With the paid version, you can save maps to your phone for offline use.

Storm Radar

Last but not least… There’s no shortage of weather apps for your phone. I have one that I use for the usual weather forecasts: daily, hourly, and so forth. I also use Storm Radar (The Weather Channel) and it has saved my bacon on a few occasions.

Storm Radar. Fortunately, there was no rain in view when I captured this screenshot.
Storm Radar. Fortunately, there was no rain in view when I captured this screenshot.

Of course, Storm Radar‘s radar display lets you see exactly what’s coming your way. What I really like, though, is the real-time rain and lightning alerts. Even if I don’t have the radar display up, Storm Radar gives me a heads up on nasty weather headed towards me. There have been times when this app helped keep me and my gear from getting rained on.

Wrap-Up

So these are some of my favorite apps for portable operating. I didn’t cover any apps that are specific to ham radio but I may do that in a future post.

Do you have any must-have apps for outdoor operating? Let me know in the comments.

72, Craig WB3GCK

 

Links

[My usual disclaimer: This blog is not monetized in any way. I have no financial interest whatsoever in any of these products.]

OK. With that out of the way, here are links to the apps mentioned in this post:

 

Another JS8Call Newbie

Yep, that’s me. At an ARES-RACES meeting the other night, a few fellow members were discussing JS8Call. I decided to download the software and give it a whirl.

After installing the software and looking it over, I watched a few YouTube videos to learn how to use it. Once I thought I had the basics down, I fired up my KX3 to take JS8Call for a spin.

I didn’t see any activity on the waterfall, but after a while, I was able to decode a transmission on 20M. That was a good sign. I called CQ few times with no response. Checking PSKReporter, however, I saw spots from as far away as southern California. Not bad for 5 watts and a rainspout antenna.

My initial CQs with JS8Call made it out to southern California on 20M. Not bad for 5 watts and a rainspout antenna!
My initial CQs with JS8Call made it out to southern California on 20M. Not bad for 5 watts and a rainspout antenna!

I dropped down to 40M and saw immediately saw a few decodes pop up. I called CQ a few times and received a call from N4YTM in North Carolina. Gordon, as it turns out, was only slightly more experienced with JS8Call; I was his third contact. Despite our collective inexperience, we had a nice, albeit slow, chat with this new mode.

I found that carrying on a basic QSO with JS8Call was pretty intuitive. I still have a lot to learn about some of the more advanced messaging features, though. JS8 is an interesting mode and less robotic than FT8. It’s slow for a keyboard-to-keyboard chat mode but I was decoding signals I could hardly see on the waterfall.

Although CW will always be my primary mode, I’m sure there will be more JS8Call activity in my future.

72, Craig WB3GCK

Logging: Keeping Track of it All

Going all the way back to my Novice days in the mid-70s, I’ve always been a bit anal…  er… diligent, when it comes to logging contacts.  Years ago I started using logging software and that diligence persists.  Over the years, I’ve evolved to a logging process that I’m sure some would find overly complex.  It’s actually not that bad and it works well for me.

I use a variety of methods to capture QSO information.  Eventually, everything ends up in one central log.  From there, all QSOs are uploaded to Logbook of the World (LoTW).  The diagram below shows how everything ties together.

Overview of my logging process. In the end, all contacts end up in the Main Log.
Overview of my logging process. In the end, all contacts end up in the Main Log.

Here are the main components of my logging system:

ACLog.  I use this software by N3FJP for my main log.  All QSOs, no matter how they are made or logged wind up in here.  Because most of my HF operating is done while portable, I added a few custom fields to keep track of where I was (MY_QTH), what rig I was using (MY_RIG) and what power I was running (TX_PWR).  Everything in my main log gets uploaded to LoTW.  ACLog makes it very easy to do that.  For casual operating at home, I enter the contacts directly into ACLog.  Same goes for paper logs from portable operations with just a few contacts.  For larger batches of contacts, I might resort to other methods.

ADIF Master.  I use this great piece of freeware a lot.  It allows me to take an ADIF file and easily add in the custom fields I keep track of and do a quick bulk edit to populate the fields for all QSO records in the file.

Fast Log Entry (FLE).  I wrote about this software in an earlier post.  This came in handy last year for National Parks on the Air activations.  When I used paper logs for activations, FLE gave me a fast way to enter the QSO data and generate an ADIF file.

SKCC Logger.  I use AC2C’s SKCC Logger software to log all of my Straight Key Century Club contacts.  This software does automatic lookups from the SKCC member database when you enter a callsign.  It also helps keep track of award levels and generates award applications.  From SKCC Logger, I generate an ADIF file for further editing and importing into ACLog.

fldigi.  Every now and then I get on a digital mode kick.  Initially, I use fldigi’s internal log and export an ADIF file.  I haven’t worked JT65 or JT9 in a while but, when I do, I export an ADIF file from the WSJT-X software.

HamLog.  When I’m away camping for a few days, I use HamLog on Android cellphone to log my contacts.  If I have a cell connection, I can do QRZ.com lookups while logging a contact.  I export an ADIF file when I get home.  After, editing the ADIF and successfully importing it into ACLog, I go back to HamLog and clear out the log file so I’m ready for the next trip.

Contest Loggers.  When I use a specialized contest logging program for a contest… Well, you know the drill.  I export an ADIF file, edit in my custom fields, and ingest it into ACLog.

So, that’s it in a nutshell.  It probably sounds complicated but it has all become second nature to me.  I’m not suggesting that you do the same but, perhaps, some of the utilities and techniques will be useful to you.

I hope to see you somewhere down the log!

72, Craig WB3GCK

Fast Log Entry (FLE)

I recently discovered a very useful piece of software.  Fast Log Entry (FLE) is a small text editor that lets you quickly get your QSO information from paper logs onto your computer.  I originally installed FLE about a month ago but I didn’t immediately see its benefits.  After taking a closer look at it, I have now added into my logging utility “toolbox.”  FLE is a free download from DF3CB, although donations are welcomed.  It is a Windows application but it runs great on Linux under Wine.

Here’s a typical use case for me.  Quite often, I’m operating portable and logging my contacts in a small notebook.   If there’s a small number of contacts, I could just enter them into N3FJP’s ACLog, which I use for my main log.  However, entering into ACLog can be a little tedious if I have a significant number of contacts to deal with.  This is where FLE comes into play.

FLE provides a simple, keyboard-only, way of entering the information.  It uses a very simple format for the information.  To get started, you enter the date in the format YYYY-MM-DD.  Then, enter the band (e.g., 40m, 20m, etc.). Similarly, for the mode, you can just enter it (like “CW” or “SSB”).  See the screenshot below for an example.

Fast Log Entry (FLE) main screen
Fast Log Entry (FLE) main screen

You can now start entering your contacts.  Once you enter a contact at a particular time, you only need to enter the portion of the time that changed for the next contact.  For example, let’s say you worked a station at 1510 and another at 1511. After you enter the contact at 1511, you only have to enter “11” (i.e., just the minutes) for the next contact.  If you run a string of stations, you only need to note the time periodically in your paper log (say every 5 or 10 minutes).  FLE will interpolate the time for your contacts after you enter them if you like.  Also, there’s no need to worry about capitalization; FLE takes care of that.  You can enter RST (send and receive) information, or let it default to 599 or 59.  You can populate the “comments” field by enclosing the comment in angle brackets <>.  You can also add grid square information by prefacing it with a pound sign, like “#FN20.”

After you have finished entering your contacts, you can easily export an ADIF (Amateur Data Interchange Format) file for ingesting into your logging program.  FLE will also let you create a Cabrillo file for contest submissions.

My brief attempt at describing FLE probably doesn’t do it justice.  I recommend going to the author’s website to download a copy and taking it for a spin.  Be sure to check out the step-by-step instructions on the website.  Another great resource is a video by VK5PAS.  He gives a very thorough introduction to FLE and explains it much better that I can.  Although his video is targeted at the WorldWide Flora and Fauna program, it is a great tutorial on using FLE.

So, if you do a lot of portable operating with paper logs (think SOTA, NPOTA, IOTA, WWFF, etc.), take a look at FLE.

72, Craig WB3GCK

YFKtest Logger

I’m planning to take part in ARRL’s National Parks on the Air (NPOTA) event next year.  In fact, I plan to activate Valley Forge National Historic Park on New Year’s Day.  It will likely be cold so I plan to operate “stationary-mobile” from the cab of my pickup truck.  I suspect there will be a lot of “chaser” stations so I’m planning to use a computer for logging and sending CW.

I considered a couple of options.  One is to use N3FJP’s ACLog on my Windows laptop.  I use ACLog for my main log and I’m very comfortable with it.  The drawback is that my Windows laptop might be a bit large for the cramped cab of my little truck.  That led me to using my little Acer netbook computer, which runs Ubuntu Linux.

In my search for a contest-type logger for Linux, I tried several programs before stumbling across one called YFKtest.  YFKtest satisfied my three main requirements for a logging program:

  • It has to be simple to use with keyboard input only; I don’t want to have to use a mouse.
  • It needs to provide programmable CW messages and be able to key my transmitter.
  • It has to have the ability to export logs as ADIF files that I can import into my main log.

YFKtest main entry screen
YFKtest main entry screen

Fabian DJ1YFK is YFKtest’s original author while Bob Finch WY9A currently maintains the software.  Since it has been around for a while, the code base is stable.  YFKtest is a PERL program, so it runs under Linux.  It supports a large number of contests, including some QRP contests.  It generates CW over a serial or parallel interface, as well as via Winkey.  It works with the same serial interface that I use with the N3FJP software, so that’s a plus.  If you are so inclined, YFKtest will do rig control using the hamlib utilities. It also generates ADIF, Cabrillo and contest summary files.

YFKtest screenshot showing my custom CW messages
YFKtest screenshot showing my custom CW messages

Installation on Linux was straight-forward.  The user interface is a bit “old school,” compared to other logging software.  It was, however, easy to configure and use.   For NPOTA use, I took the “DXPED.def” definition file for DXpeditions and made a few minor tweaks to it. To give myself some peace of mind, I created a cron job in Linux that automatically backs up my log files to an SD memory card every 15 minutes.

YFKtest is hard coded for “599” or “59” signal reports.  There may be a way to accommodate honest signal reports, but I haven’t explored that yet.  Since LoTW doesn’t use signal reports, this is a non-issue for NPOTA logging.

Bob Finch’s support is top-notch.  During my initial testing with it, I reported a bug in the ADIF files.  In a day or two, Bob uploaded a fix.  You can’t complain about support like that.

So, I’m going to give YFKtest a shot for my New Year’s Day operation.  I’m anticipating a lot of NPOTA activity on the first day and that YFKtest will help me keep up with it!

For more information, visit the YFKtest website.

72, Craig WB3GCK