Setting Up PSKReporter for Real-Time Propagation Monitoring
I started using PSKReporter about seven years ago after someone in a local digital mode group pointed out that their WSPR calls weren't registering anywhere they could see. It turned out their power supply was sagging under load and they were running maybe 15 watts instead of the 5 watts they thought. The reporter showed the groundwave-only signal. That was the first time I understood just how transparent real-time propagation reporting can be when you know where to look. PSKReporter is a free web-based platform where amateur radio operators who run certain digital modes submit received signal reports to a central database. The "real time" part comes from WebSocket connections that push reports to a live map showing signal paths, frequencies, and power levels as they happen. It covers JT65, JT9, WSPR, Q65, and JS8 Call modes. Not every mode has equal coverage because the submission frequency and bandwidth requirements differ between them.
Pskreporter Real Time Amateur Radio Propagation Essential Tool For Radio Amateurs
The actual setup takes about twelve minutes if your software is already configured for broadcasting. Here is the sequence that works without frustration. First, download and install the latest version of the digital mode software you plan to use. If you are running WSJT-X 2.7 or newer, open the Configuration window, go to the Advanced tab, and toggle on the PSKReporter option. Enter your Callsign, Maidenhead locator grid square, and antenna information. You do not need to create a separate account on the PSKReporter website for WSJT-X to send data. The software handles the handshake automatically through the PSKReporter API. If you use JS8Call instead, open the Preferences menu and navigate to the Logging section. Check the box for PSKReporter and enter the same identifier fields. JS8Call uses a slightly different submission cadence than WSJT-X, so you will see your contacts appear on the map with a longer delay, typically 30 to 90 seconds after the exchange completes rather than immediately.
The third step is verifying that your computer's firewall allows outbound connections on the PSKReporter ports. I lost an entire weekend trying to debug why my WSPR spots were not appearing until I realized my router's default firewall rules were blocking port 8080, which some versions of the reporting client attempt to use as a fallback when port 443 is saturated. Checking the logs in your digital mode software will show connection refused errors if this is the issue. Once the software is pointing at PSKReporter correctly, go to pskreporter.info and search for your callsign. If you see nothing after fifteen minutes, confirm that your mode is actually transmitting. In WSJT-X, check the Mode field in the upper right corner and ensure it is set to WSPR or JT65 rather than FT8. The most common reason people think PSKReporter is broken is that their software is simply not running the mode that submits data. Here is something most beginners miss about the real-time map. The dots you see represent individual received signals, not continuous path tracking. A single dot might be one operator receiving another operator's 10-second WSPR burst. The line connections you sometimes see between stations are derived from automated analysis, not from the reporters themselves. Do not treat those lines as confirmed working paths. They are probabilistic correlations based on overlapping reception windows and geographic proximity.
Get the Full Details

I ran into a specific edge case during a summer sunspot minimum when I noticed that my PSKReporter spots on 6 meters were showing up consistently but with reported signal strengths that did not match my receiver's S-meter. I was running 100 watts into a dipole at 30 feet and seeing reports from 800 kilometers away with S9 plus readings, while my own receiver showed barely above noise. The issue was that the PSKReporter signal reports come from the receiver that logged the spot, not from your own rig. When another operator far to the north was hearing me on a sporadic-E path, their report reflected their receive conditions, not mine. I had to cross-reference multiple operator reports to estimate my actual transmit efficiency, which took about twenty minutes of manual checking. There is no automated way to pull your own effective radiated power estimates from the database. Another counter-intuitive point that nobody mentions in the quick-start guides is the relationship between your grid square accuracy and your visibility on the map. If your maidenhead locator is off by even one character, your spot gets placed in the wrong grid cell, which shifts your apparent position by roughly 14 to 30 miles depending on the latitude. This means other operators in the adjacent grid may incorrectly attribute your signal to their own reception conditions. Double-check your grid square in the PSKReporter configuration against what your GPS or topographic map shows. I use the ARRL Grid Locator tool to verify before every contest season. The limitations of PSKReporter deserve equal attention. The database only contains data for modes that actively submit reports, so HF SSB, AM, and CW operators get nothing from this platform. The real-time feed depends entirely on the density of reporting stations in your region. If you are operating from a rural area with fewer than fifty active PSKReporter-enabled stations within a thousand kilometer radius, your spots will be sparse and the propagation paths you can infer from the map will be unreliable. During the 2024 solar cycle decline, I watched my 2-meter EME reports drop to fewer than three per day because the number of operators actively submitting data decreased by approximately sixty percent.
There is also a latency issue that affects how useful the tool is for making real-time QSO decisions. Reports from WSJT-X typically appear on the map within five to fifteen seconds of transmission, but reports from slower modes like JT9 can take two to four minutes to propagate through the server cluster. During a brief VHF opening last spring, I relied on the PSKReporter map to confirm a path to Florida and called CQ on 6 meters based on what I saw. By the time the spot appeared, the skip had already moved eastward toward Europe. The map told me what had already happened, not what was happening. For actual real-time path identification, you need to combine PSKReporter with a live waterfall display and pay attention to the current band conditions yourself. If your primary goal is monitoring propagation rather than making contacts, I would recommend pairing PSKReporter with the WSPRnet map for long-term path statistics and with HAMVOIP or similar live chat rooms for real-time human observations. PSKReporter alone will not tell you whether a band is open right this second because the data lag means you are always looking at the recent past. The tool is excellent for post-QSO analysis and for understanding long-duration propagation patterns across weeks and months, but it is not a crystal ball for sudden ionospheric changes. The download links are straightforward. WSJT-X is available from wsjt.io, JS8Call from js8call.com, and the PSKReporter web interface at pskreporter.info does not require installation. Everything runs through your existing digital mode software once the configuration options are enabled. There is no separate client application to update or maintain beyond the mode software itself.
The platform does not charge anything, but it does rely on volunteer station submissions to remain useful. If you run any supported mode, enabling the PSKReporter submission option takes less than a minute and provides data that operators worldwide use to chart propagation conditions. Even if you are only listening, participating keeps the dataset dense enough for the probabilistic path analysis to remain accurate across large geographic areas.
