Logging QSO’s – What is it? and how to select the best Logger

Topic	Logging QSO’s – What is it and how to select the best Logger
Subtopic	Logging
Equipment Required	Computer + Internet
Costs	Nothing or a small costs for backup system/replication
Document last reviewed and updated (reviewed each year)	24th October 2026 – major rewrite and additional detail and heading change

This is probably one of the most polarising subjects in Amateur Radio.Everyone has their favourite logging system, and it very much depends on what their Amateur Radio interest is, such as Fixed Shack Location, multiple Shack locations, POTA, WWFF, SOTA, heavily into contesting, or working the various other interests, such as IOTA, LOTA, BOTA, COTA, SiOTA, etc (I will leave you to look up what these are).

Just one thing I want to get out of the way is what the QSO and QSL terms mean…..

• QSO – A QSO is a contact between amateur radio station
• QSL – A QSL is an acknowledgement or confirmation of that contact, which may be exchanged using a physical QSL card or an electronic confirmation service.

Going back to years gone past (and some still currently), paper logging was the standard. Every QSO was logged on paper. It became your one place you logged every single QSO, whether it was in the shack or out in the field. Everything was logged there.

Since the early 1980’s when “home” computers (Apple II, TRS80, Commodore) started to appear, many Amateur operators, who had a little knowledge of Basic or database tools, started creating their own logging programs. At first these were nothing more than a replacement for paper and pen, just a convenient place to store their logs, but these started to evolve through the 1980’s, implementing new features, and using more modern programming languages such as Pascal, Assembly, and C, as well as using more established databases such as DBase etc.

However, whatever method you used, at its core, the main purpose was to maintain a list of all your QSO’s made. Historically, and this is based on various anecdotal notes, it was as requirement in many countries, but from my understanding it ceased to be a requirement in the U.S. in the early 1980’s, and in Australia in the early 2000’s. However, most Amateurs do continue to log every call, especially with improvements in logging applications and access to computers or similar devices. It also became important as QSO confirmation moved from paper QSL Cards (which was very labour intensive to check – for you and the authorised checker) to electronic confirmation through services such QRZ.com, LOTW, eQSL, which require you upload your logs to these services, and the other party also uploading their QSO’s to these systems which result in a confirmation (if the two logs match) or in other words a QSL.

Let’s have a quick look over the typical work flow before we move on, and coverage of terms used in this article

• LOTW – ARRL’s Logbook of the World – Online QSO/QSL submission system
• QRZ.com – Very popular Online QSO/QSL submission system
• eQSL – less popular QSO/QSL system, but with a focus on Electronic QSL Cards

As you can see, the Logging software is pretty central to the whole setup, your choice of Logging software is critical. The above diagram is pretty well representative of a “connected” hamshack, but with other applications connected, it can become more complex. Just a quick explanation of the items in this diagram:

CAT Control or Similar – Flrig or Omnirig or HAMlib

The first connection (which is still optional – as you can manually type in the frequencies / band / mode etc) is the connection from your radio to your logging software. Via CAT control or similar interface, the software automatically populates the frequency, mode and band and power if available. Some logging software also allows control of the rig (frequency / band / etc from the logging software). For most hams, this is really a must have and in most cases, especially with rigs with CAT control, this is quite simple to do.

Your Primary Logging Software

Naturally this will be your choice based on features and connectivity. I’ll discuss how to select logging software later in this article. For now, this illustrates its role as the central component of the system

eQSL

eQSL was one of the first services that I setup. Once I realised that physical QSL cards were not used as much nowadays, I went looking and came across eQSL. Immediately under their free plan, I setup a basic QSL Card, and later upgraded by subscription to use my own backgrounds. Other hams who are part of eQSL will receive your return eQSL card. If you are not a member of eQSL, setup an account today. Once you join, you may find that some of your contacts have already sent you eQSL cards.

Another well known online logging service, however using a certificate based submission system to avoid QSL fraud. Matching confirmation can qualify for award credit under the relevant rules

LOTW – Logbook of the World (ARRL)

Main delay is getting yourself authenticated with paperwork (via email). Worth doing.

QRZ

Probably one of the larger online services . They offer a free service as well as a subscription service. My understanding at the time is that if you are in the FCC licence database, the system will verify you. If you are international, you need to go into the forum and ask them to verify you manually. This part took me a few weeks to work out (as it is not clear). Anyhow they will send you a verification email, and you can then use QRZ.com

ClubLog

Club Log is very popular within the amateur radio community, especially for HF (High Frequency) DXers, contesters, and major DXpeditions, and is also supported by the WIA as a confirmation system.

WSJT-X

This is probably the last piece of the puzzle. WSJT-X is an application that is used with FT8 / FT4 and other digital modes. It communicates with some of the logging applications such as Ham Radio Deluxe, N1MM, Log4OM via UDP. This means as you complete a successful FT8 QSO, it will automatically log the QSO with your logging software (if it supports it), and as I mentioned, when you finish your session (close the logging program), it will update your external logs / services. The amount of time this saves makes Amateur radio with its automation enjoyable.

Whilst we have listed WSJT-X as an example, there are probably several others, such as JS8Call.The best way to determine whether a program supports integration is to look in its manual for information about UDP. This will generally, but not always talk about UDP QSO logging. Each system will be a little different. However be aware that UDP is being used more and more as a quick verbatim way of communicating QSO’s. As an example, an application called GridTracker (nice program) receives QSO information directly from WSJT-X using UDP.

Again, this subject is not meant to be in-depth and only to provide an overview. It took me many months to work out the pieces of the jigsaw, and the UDP part a little longer. Once you work it out, you will find how easy it actually is when you have an overview of what you are trying to achieve.

Gridtracker

This is not absolutely essential as part of your logging system, but it does demonstrate how the fabric of this system comes together. In simple terms, I set WSJT-X to send logging over UDP to Gridtracker, which is setup to receive these UDP packets. Now when we talk about sending and receiving, whilst this can be between networked PC’s, it works just as well all on one PC.

What we now have is live information appearing in Gridtracker showing us live conversations between operators, who is hearing us, showing the QSO’s that we have had. And along with that, we can have it monitor for stations we are chasing under various awards, as well as personal alerts for stations we were watching out for.

The one thing you need to be aware of is that Gridtracker can send your WSJT-X logs direct to the online services as well (if that is what you want). Ideally, you should let Gridtracker log to your primary logging software, but not both as you could end up with duplicate logs.

What services do I really need to upload to?

All you need is the services that you require. eQSL is used as I like sending eQSL cards to other eQSL users. Simple and it works. QRZ and LOTW are used as they are the two heavyweights of the online services. LOTW is used for DXCC, WAS and other ARRL awards. You need to investigate for yourself, whether you need the service, whether you need your logger to support the service. For instance if you check, you can get QRZ to automatically sync from LOTW (at a cost), so that is one less you need to worry about. A lot of hams have reported that they get a lot more confirmations on QRZ than they do on other services.

With Electronic logging (as mentioned before), you will find that it has become a lot simpler in terms of physical effort, but you still need to provide them exactly as per the rules laid out by the Award Provider/Sponsor. As an example, the WIA DXCC award states that “Paper, eQSL and Logbook of the World (LOTW) are our current acceptable confirmation standards”, but they also make it clear that Excel logs are no longer accepted.

So if you were an Australian operator going after just the WIA awards, then you might set up eQSL and LOTW and ClubLog as your main online QSL confirmation services. Just be aware however you are still required to upload a full ADIF file to submit for the Award you are chasing, and they specifically warn about uploading raw logs from the various Online Services. It should be from your logging system. The WIA will validate your uploaded logs against the confirmation services mentioned.

However, with QRZ.com being one of the larger ones, you may also want to have your logs submitted to the QRZ.com site as well, as it had a great tracking system showing what awards you are eligible or almost eligible for.

You might be wondering how these services matches QSOs between the two parties, and this is a generalisation, so you should check the services individually for their parameters and how they match.

• Call Signs – must match
• Band – generally they match on band, not down to the exact frequency
• Mode – must match
• Date – must match
• Time – must generally be in a 30 minute window of each other (but again check the individual service to confirm)

These last two criteria (date and time) are the most common reason for QSL failure, in either providing a UTC Date that is a local date (which could be a day in front or a day behind depending on where you are in the world) or a local time instead of a UTC time. Once you have your logging software setup properly, this generally does not happen, but it can happen if you change your software, or you do a lot of re-syncing/exporting and reimporting of your logs, especially with the online services (more on this next).

Selecting a primary logging application (criteria)

Now, given a little history on logging, this is where the simplicity of modern logging goes out the window. I recently held a small discussion with a few new hams and a few experienced hams on how they log (at the higher level – not what software they use – but their process). Now to be fair, this was not a representative group (number is way too small for a sample), however it clearly showed no one person had a relatively complete picture of how it all works (the mechanisms), what happens when particular services fail, when applications fail, when logs get corrupt, when hardware fails, and their recovery methods and even what control they had over privacy (especially comments in logs).

I found that many users just log to a web based service (like LOTW and/or QRZ) or use an Internet based logging program (e.g. World Relay League). With many that I spoke to, there was no clear plan of what was their “master” log book, and even with these Internet logging solutions, what their backup solution was.

I realise we are not talking about big business here, but it is something that needs to be given some real thought and some initial planning. I have been involved in IT for the last 40+ years, so I have seen what occurs, what can occur, as well as things that come out of left field. My brain is wired, that every move I make in IT, that it has a process, it has a back up plan, it has a recovery plan, it has a test plan and a validation plan. Yes, again we are only talking about your logs here, but for some that has taken years of effort, and it can hurt when you lose your logs, not to mention trying to claim awards.

A few of you are sitting back, saying my logs are working, I have everything on QRZ.com and LOTW, and nothing has happened in years, I don’t need to put any effort into it, and if that is the case then that is great. However, how long that works for you is anyone’s guess, and these reasons are becoming more apparent over the last few years such as

• LOTW had a cyber attack/ransomware incident which impacted greatly on their systems/services.
• New Vulnerabilities found in PHP (Oct 2026) which can impact some of these services.
• Loss or Impact to overseas Internet cables (happening more and more)
• Businesses closing up (due to economic impact or government processes becoming onerous)
• What else is round the corner that we are not aware of

They were the internet related issues, and then we have the local issues

• Workstation failure or loss
• Personal economic hard times resulting in trimming online services (this could include retirement)
• Being personally hit by ransomware
• Corruption of data syncing to these services
• Upgrading logging software causing issues with formats

I am not looking to scare you, in fact many of these things do not happen without you having some idea they will happen, but it provides the background for what I am recommending in terms of the system you use. Also let me be very clear. Any online or local system can fail or be attacked no matter how good they are, and this is what we should keep in mind. Similarly if your local system is hit by a ransomware attack, having your log back up files, not physically connected to your PC is one of the safest ways to avoid loosing all your files.

Logging System that works across most major platforms

• Whilst you might be just a Windows user now, you don’t know what you will be using in 3-5 years time, so ideally you want to select a logging system that can work on any device you want without having to make compromises. I know I probably won’t be using Windows in my retirement years (due to costs of the Microsoft eco system), so planning for that now is paramount.
  
• Having a Logging system that works on all major platforms allows me to have solutions for portable or field logging. I can use a tablet or phone for portable logging, and depending on your solution, it will probably sync to your main PC, this gives me maximum flexibility.

For many, the application that they are using now, was based on the operating system that they are running. Going back 5-10 years ago, many decent feature laden logging applications were only available for one operating system, and this was primarily due to the developer committing to a language or windowing library system. Over the last few years there are many new tools that will now compile for multiple platforms using libraries/functions that are operating system agnostic, so of late there are a lot more choices of logging software that works across many platforms, and has the same look and feel across all the platforms.

A Single Logging Database for all your QSO’s

• Implement and maintain control of your logs. Setup your master log on your HamShack PC.
• This will be your master log for every QSO you make, whether that is a contest, POTA / SOTA / WWFF, or just general HamShack logging
• Even your SOTA/POTA/WWFF logs will should sync back to this database, even if kept on separate devices.

Log Submission systems / Export system

• The system you select should be able to export the appropriate log format for the service you wish to submit to and these formats should be at least
  • Full ADIF Export (.adi)
  • POTA adif
    SOTA adif
  • Cabrillo Logs which is generally used for Contest logs (which are not an adif standard log)

• Whilst not critical, the ability to export these logs automatically from the application straight to the online services is used by many. However, many Amateurs prefer the manual function of submitting the logs manually themselves, to check that the information is correct, to be able to confirm it has worked, and validate it once complete.
  
• As a minimum, the log system must be able to export a file in the correct format without you having to massage it. It should be as simple as exporting your last POTA operation to a POTA formatted file, and submit it.

• Another reason for maintaining control of your log submission is that you can review your logs before you submit to these services, allowing you to delete any duplicates, correct errors at your level, because once they are uploaded, you are restricted on what you can do on the online services e.g. LOTW, you cannot delete a QSO once it has been submitted, and on QRZ.com, you can delete unconfirmed QSO’s but not confirmed ones. These are not failings in their systems, but strict rules they have in place (for good reason), but the work you need to do to get these resolved can be cumbersome, and realistically when you go to do an export of your logs (if doing a data recovery), the integrity of your logs with all these fixes does not provide the confidence you want.

Just as an FYI for those that have not looked at the ADIF file standard, whilst it is a standard published structure, with POTA / SOTA / WWFF logs, the difference lies in how they encode reference identifiers (activator and park/summit tags) using either official ADIF standard fields or legacy/custom SIG fields

Backup Systems

Now this one is important and quite often may take several forms or methods.

• Your HamShack Workstation backups are probably your primary backup solution, not just for your logging system but for all your applications (and configurations) that you have installed over the years. However whatever backup tool you use, it should be automated. Relying on you remembering to do it on regular intervals is not the way to go. Ideally a system that can do bare metal backups (e.g. operating system and data) is the way to go (as it will save recovery time), but as a minimum at least ALL data, and ideally this data should be backed up to an external hard USB drive as a minimum, or ideally using a cloud back up option. These backup solutions used to be costly, but products like Veeam (community edition) for Linux and Windows are free for local USB drive backups, and products like TimeShift on Linux systems will allow you to recover your systems with some confidence to exactly the way it was before your data failure (whether it was a hard drive failure, equipment failure etc)
  
• Ideally the logging system you choose should have its own independent cloud based backup system, clear of any online actual logging system such as QRZ.com, LOTW or similar system. And this is a particular mistake that many make believing that these systems take their logs verbatim, and will be able to export that exact same information (e.g. doing a recovery). Whilst on the whole, these systems do the job, however QRZ.com is known for replacing your QTH field with your QRZ.com default field. This is not to say that your chosen logging system cloud backup system may never have an issue like this, but it is more likely that that you can get some community or paid support to resolve this. Whilst these independent cloud backup services generally have a cost per year (say $60 or so), it means that you would spend less on your workstation backup solution, using a local USB drive instead of another cloud solution for this.
  
• Your own manual export of your “FULL” adif file export. Your logging system should include this as an export capability. Most are now clearly marking that it is a “full” adif export. Whilst I have a cloud backup as part of my solution, once a month, I export a full ADIF file and upload it to one of the other cloud repositories such as onedrive or Google Drive. Might as well make use of these services.
  
• And finally, one back up system you may not have considered, especially if you are using a log cloud backup sync service, is that this option means if you use more than one device to do your logging (e.g. laptop or tablet for SOTA/POTA/WWFF) is that should you lose your main HamShack PC is that your logs have been synced on all devices, the same unadulterated log file, as well as that it is in the cloud, so if for some reason you need to replace or upgrade your laptop, phone, HamShack PC, you only need to install the latest version of your logger onto this device, add the cloud account email address, and your log files are restored to your new device.

Like always with backup solutions, don’t rely on one method, select a primary method and a secondary solution. Think through the possibilities of what could happen and what your options are.

Testing and Validation of your backup/recovery solutions

• Now one of the most important parts is testing your recovery methods on a regular basis. It is probably one of the main areas that is overlooked or avoided, preferring to “wing it” until needed.
  
• This is where it can all go wrong, finding your chosen backup solution has not been working for months or even years, and finding your re-import of your ADIF logs you submitted to online services do not contain the information you previously had or the format is not the same, and you spend hours or more trying to reconstruct. For many it is too complex or fraught with risks, that they do not test it, and I get it, been there, done that.
  
• That’s why I like the log cloud sync functionality, as it is one that I can test regularly without impact to my current systems. It is in most cases as simple as finding a spare PC or device, install the Logging application and connect it to the Cloud Sync Service, and check that it syncs your entire logs to this “temporary” device – test done – simple. What’s even better is that this “test” device, can be an Android, Windows, Mac, or Linux device that you have not used on this service before. Even if your test system is only setup with Linux, and your main logging device is Windows, it should restore your log perfectly. The confidence that this provides cannot be understated, especially if you do it on a regular basis. This is also why having a logging system that works across multiple platforms is extremely useful.

Conclusion

In closing off this article, I have included some logging systems of note, ones I have particularly experience with. Especially for this updated article, I have reviewed no less than 20 other applications (including some of the newer online applications), with many of them not making the shortlist due to lack of development, missing features, missing sync functionality or some other reason based on a lot of the criteria above.

• Ham Radio Deluxe – https://www.hamradiodeluxe.com/ – $US99 – I have reviewed this (30 day trial). Nice product, but did it have $AU150 worth of value? I could not see it at the time (against the free options) – Software is Windows only
• CQRLOG – https://www.cqrlog.com/ – Free – this explains it better – https://www.cqrlog.com/about – looks good as a contesting log – software is Linux only
• Log4OM – https://www.log4om.com/ – Free – Nice looking, works well and integrates with products and services and was my software of choice previously – software only works on Windows
• Ham2k – Power Logger – https://ham2k.com/ – Free – very powerful logging solution (has now become my software of choice – Works across almost every platform – supports offline logging (e.g. SOTA/POTA on portable devices. This product is also known in an earlier (and still current) product call POLO which was mainly for portable use and Ham2k is the next evolution of this product. Currently the product is in Beta, but it is one of the most solid beta’s I have seen and there is a lot of development and support on this product
• WaveLog – I will give this one an honorable mention and was very close to the one I recently chose. However, one its main failing was meeting all the criteria I set out, and this included support on a range of devices and operating systems. Some things can be worked around, but it increases the complexity, which is a risk, especially if not all from the same developer

Note that I have provided the names of products that I have either reviewed for my use or I have really spent some time looking into it (manuals / integration / other peoples views). I have provided the links to the sites so that you can have a look at these and make up your own thoughts (and test them), but in your reviews, look at the following.

• Many support videos?
• How active is the development? – This is particularly important.
• Is there a big gap in development (lack of interest?), or on the upside, did they completely rewrite the product to make it meet the new requirements, make it faster, use new databases etc?
• Does it support integration with all the services and platforms you use now and want to use in the future.
• Is the development team responding to bugs? Check the forums
• Read the forums / public discussions, has the developer has a good set of goals and a real plan, especially adding features that may be not be available yet, and have they got a track record of delivery.