Digimode Automatic Propagation Reporter

This started out as a project to automatically gather reception records of digimode activity and then make those records available in near realtime to interested parties — typically the amateur who initiated the communication. The way that it works is that many amateurs will run a client that will monitor received traffic for callsigns (the pattern 'de callsign callsign') and, when seen, will report this fact. This is of interest to the amateur who transmitted adn they will be able to see where their signal was received. The pattern chosen is typically part of a standard CQ call. The duplicate check is to make sure that the callsign is not corrupted. The rules for protocols like FT8 are different as the callsigns are protected by error correction. You do still need to call CQ in order for your signal to be reported.

The way that this would be used is that an amateur would call CQ and could then (within a few minutes) see where his signal was received. This can be useful in determining propagation conditions or in adjusting antenna and/or radio parameters. It also provides a scientific archive of reception records that is being used for ionospheric research purposes. These records are also maintained for legal purposes as there are multiple government licensing authorities that make use of this data in their investigationsi -- typically verifying that licensed amateur radio operators are abiding by their licenses.

There is a map display of this information.

There also a page of statistics about the project.

If this is interesting to you, then please contact me at the email address below to see if there is a client for your digital mode decoding application, or you can contact the author of your package directly, and point him at this page.

Note: This system does not transmit any signals over the air, it just makes use of existing signals that are being transmitted by people calling CQ. This approach is different to some other propagation reporting tools, and has the advantage that adding more monitoring stations provides better coverage without consuming any bandwidth. Also, you don't need to have an amateur radio license to participate. All that is needed is an antenna, a radio and a computer, and you can start monitoring. You will need to pick a 'callsign' to send in reports under — pick something with your country prefix on it, such as W/SWL/BOSTON for US, shortwave listener in Boston.

Current Uses

Many of the monitoring stations like to use this for bragging rights. It is also interesting to see how long it takes to spot 100 different countries. (A well placed station with a decent antenna can do this within a week of monitoring, but the best systems can do it within a single day).

The data being gathered also includes more than just PSK spots, it include JT65 and FT8 -- with FT8 the overwhelming majority at the moment.


This is the client that most people use for decoding FT8. It includes integration with PSK reporter. To enable reporting, you need to enter the following information into the settings or preferences panel. Note that WSJT-X will only report signals that are standard messages containing the sender's callsign and their locator. Most often these are CQ messages, but messages of the form "Call_1 Call_2 grid" and "Call_1 Call_2 R grid" also work. Note that non-standard messages will not be reported.

Digital Master 780

The reporting client is now integrated into the current version of DM780 (part of Ham Radio Deluxe). This makes it a painless operation to install and use. There are typically over 100 active monitors during the day, mostly in North America and Europe, which means that your call is likely to be heard. More monitors from other parts of the world would be much appreciated.

To enable reporting in DM780, you need to go to the 'Tools' menu item, and then select the 'PSK Reporter' option. This will open a dialog box, and you just check the 'send updates' checkbox, and you are done. Now, whenever the SuperBrowser detects a callsign, this information will be forwarded to the database and made available for other interested parties to view.


fldigi 4 (a multiplatform digital mode program) now has builtin support for logging data to the pskreporter web site. This program is popular on Linux, and also, being multiplatform, they could not use the DLL that I provide for generating the logging messages. However, with only a small amount of help from me, they managed (in fairly short order) to build their own implementation of the message generator, and start racking up the spots.

To actually make it work in fldigi you need the information from this message.

Short answer: you want to click the Spot button in the main window.

Long answer: pressing initialize with the autospot box checked should reveal a Spot button at the top right cornet of the main window. If it is unlit, the autospotter receives no data and never calls the PSK Reporter module. This may seem superfluous, but the underlying spotting "framework" is supposed to be able to accommodate other things besides PSK reporter (none of which has yet materialised). The Spot button would then toggle all of that potentially expensive pattern matching.

Airlink Express

Reporting to PSK Reporter is as simple as clicking on the icon on the log bar. This feature is only active when the multi channel display is selected. Whether logging to PSK Reporter is active is saved in the preferences, so setting it is a one time activity.


This (as its name suggests) decodes JT65 traffic and then can log it. The master source for download appears to be the JT65-HF group, but I'm not sure.


This handles a mode called ROS that is good for weak signal work. There is controversy over whether this mode is legitimate in the US. Connecting this to pskreporter was non-trivial as the interface layer was written in Visual Basic. It turned out that the original version of the DLL didn't work correctly when using that calling convention.

UR5EQF Logger

This is a Ukranian logging program written by Vladimir Kovrizhenko (UR5EQF SK 04/19/2014) from Dnepr. The interesting thing about this is that I had no contact with the author. It does use my DLL for sending data to the pskreporter website.

For Developers

There is a version of a Windows API specification that can be used to submit the data records. There is a PSK Reporter SDK that can be download. This includes the documentation, DLL, header file, etc. This should be easier to use than generating the protocol directly. There is also a Delphi wrapper that makes it easy to call from Delphi applications -- thanks to WD5EAE.

The code used by fldigi can be found in their GIT repository. This is under the GPL so it may, or may not, be useful in other programs.

There is a complete description of the protocol used to submit the information, together with information on a test server to use.

Best Frequency

There is also a web service to provide the 'best frequency' to listen on to hear PSK31 traffic in your grid square at the current time. This is useful if you leave your radio unattended, yet controlled by software.

The basic URL is which will return data indicating the best frequency for your location (based on geolocating your IP address). If there is insufficient data, then no frequency will be returned.

The parameters to this script are:

The response document (if it contains any frequencies) will be a text/plain document, and the first word on the first line will be the integer frequency that is recommended. There are various other numbers in the document, whose meanings are not defined and may change.

Similar Approaches

There is a very similar site for the WSPR protocol called WSPR is a very weak signal digital mode protocol that uses very little bandwidth, but is not suitable for conversations.
Philip Gladstone
Server Hosting provided by Fast Serv Networks, LLC