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.
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
- On the general tab, you should enter your callsign and your locator. Enter at least a six character locator as it marks your location on the map with more accuracy.
- On the frequencies tab, you should specify your antenna (on a per-band basis).
- On the reporting tab, just check the checkbox to enable PSK Reporter Spotting.
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.
(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.
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.
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.
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.
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:
- grid= the two letter grid square. This will override the geolocation of your ip address.
- freq= comma seperated list of frequencies (in hz) that you are prepared to listen to. This should be the VFO frequency for each band. The response frequency will be one of these.
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.
There is a very similar site for the WSPR protocol called WSPRnet.org
. WSPR is a very weak signal digital mode protocol
that uses very little bandwidth, but is not suitable for conversations.
Server Hosting provided by Fast Serv Networks, LLC