Your Kiwi must be running the v1.690 (or later) release to use the proxy service and be in the public Kiwi list (,

Please visit (documentation) and (online store)

WSPR Extension

I have two questions regarding the WSPR extension (that knows as 1.3 Kiwi) where I've not been able to find answers:

Does the browser keep an equivalent spots file to WSJT-X's ALL_WSPR.TXT? If so, where might I find it on Chrome (Mac OSX) or Chromium (Pi)? I can see small files every 2 minutes in the Chromium cache but they are not readable and not what I need.

In the comments for wspr_main.cpp at are // upload spots at the end of the decoding when there is less load on

// extension: spots uploaded via javascript

I have not been able to find the javascript function to check on the exact upload mechanism, can someone point me to where it is, or describe the mechanism whether spot-by-spot, POST, or MEPT batch, or something else?

I ask as part of a study with Rob AI6VN into completeness of uploads from WsprDaemon, WSJT-X and the Kiwi extension. This extension is much used, here is a histogram of spots uploaded by package as a dip test 1t 1706 UTC on 1 December 2021. The unrecorded category includes WsprDaemon versions prior to 2.10k.


Gwyn G3ZIL


  • un-recorded might also include Red Pitaya spots which is what I think EA8BFK uses

  • He has been running wsprdaemon V 2.10k for some time

  • edited January 2022

    Is there a list of the guys with unrecorded? I'd be happy to try to track down what they run.

  • Jim,

    Thank you. I'll write a query to extract and send you in a private email.


  • Jim,

    If you reach spotters running pre- 2.10k versions of wsprdaemon, encourage them to upgrade to that version and also to watch for WD 3.0 where I have corrected some upload minor problems:

    1) WD 2.x offers type 2 spots with '<...>' as the call sign. WN appears to always reject those spots, but I can't be sure of other side effects.

    2) WD 2.x uploads the entire spot lines from ALL_WSPR.TXT, but mistakenly interprets some of those lines as 'packet mode' values. Such WSPR-2 lines are reported as WSPR-15 or FST4W-300/900/1800 packets.

    Despite those flaws, we have some evidence that WD 2.10k uploads spots more completely than other decoding programs.

  • I realize I'm probably the only one left who is *not* running wsprdaemon ;-), but here's my observation. I use the 'stand-alone' extension and let the KiwiSDR do the decoding. Here's my setup:

    KiwiSDR 1, v1.636, 8 SDR channels, 12 GPS channels | Uptime: 0:16:04 | UTC: 18:10 | Local: 10:10 America/Los Angeles (PST)

    Debian 8.11

    GPS: acquire yes, track 10, good 8, fixes 396, ADC clock 66.665916 (395 avgs)

    SNR: All 0 dB, HF 0 dB

    Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/119.0

    When I run the WSPR extension in my local browser, the spots are uploaded. However, if the 'Extensions' tab and Autorun is used to set up a band, I see the spots in the log, but they are not uploaded.

    73, Doug WW6D

  • In the admin extensions tab, under WSPR, set the Log spot debug info? setting to Yes. Then after you get some decodes look at the admin log tab for messages like the following. Check the ones that begin " said:" and see if the spot uploads were successful or not.

    I just tried it using the WSPR extension and autorun and they both uploaded fine.

    Sat Nov 25 19:36:00 00:13:31.022 .1..  1     WSPR DECODE: 1934  -1  0.6  7.040079  1  VK4LEW QG51     0   23 (200 mW)
    Sat Nov 25 19:36:01 00:13:31.734 .1..  1     WSPR DECODE: 1934 -21  0.2  7.040042  0  VK3CYD QF31     0   27 (501 mW)
    Sat Nov 25 19:36:05 00:13:36.325 .1..  1     WSPR UPLOAD: curl -s ''
    Sat Nov 25 19:36:05 00:13:36.325 .1..  1     WSPR UPLOAD: said: "1 out of 1 spot(s) added"
    Sat Nov 25 19:36:08 00:13:38.601 .1..  1     WSPR UPLOAD: curl -s ''
    Sat Nov 25 19:36:08 00:13:38.601 .1..  1     WSPR UPLOAD: said: "1 out of 1 spot(s) added"

  • OK ... here's 2 recent log entries:

    Tue May 24 20:04:15 02:09:12.150 ..2.....   2        WSPR DECODE: 2002 -25 -0.4 14.097026  0  AE0JS  DM79  1534   23 (200 mW)
    Tue May 24 20:04:20 02:09:17.198 ..2.....   2        WSPR DECODE: 2002 -28 -0.4 14.097122  0  KD6EKQ DM12   839   20 (100 mW)
    Tue May 24 20:05:41 02:10:38.325 ..2.....   2        WSPR UPLOAD: curl -s '
    Tue May 24 20:05:41 02:10:38.325 ..2.....   2        WSPR UPLOAD: said: "1 out of 1 spot(s) added"
    Tue May 24 20:05:43 02:10:40.341 ..2.....   2        WSPR UPLOAD: curl -s '
    Tue May 24 20:05:43 02:10:40.341 ..2.....   2        WSPR UPLOAD: said: "1 out of 1 spot(s) added"

    However, even after waiting for awhile, I only see these two spots on (which were received earlier using the browser extension):

    2023-11-25 17:50  VE6ATS  14.097073  -24  0  DO33cj  0.2  WW6D  CM88pk  1797  206  W-2   2023-11-25 17:50  VE6AGD  14.097045  -26  0  DO20  0.2  WW6D  CM88pk  1469  207  W-2 

    I did notice on my decode that the string is cut off, unlike yours that includes more in the verion variable. (Maybe that the log clipping?)


  • verion ... I meant 'version' variable in your curl -s string...


  • jksjks
    edited November 2023

    From the curl URL:

    mine: date=231125 (25 nov 2023 UTC)

    yours: date=160524 (24 may 2016 UTC)

    So we need to figure out what's going on there!

    That looks like the default Beagle Debian 8 image year. But NTPd should be running on Linux by default and get the correct date from the Internet. Or if you have it hooked up it will get the date from the GPS.

    It works in the WSPR extension case because spots are uploaded from Javascript in the browser. And that uses the date/time from the computer running the browser, not from the Kiwi.

    If you enable Internet connections (doesn't have to be publicly listed), and email me a temporary admin password, I can take a look and see why it's not getting the correct date. If it's not easy to open port 8073 on your router then we can temporarily setup on the proxy service which is easy to configure.

    I need to be showing an error when this happens..

  • Thank you John! ... Not sure what happened but I do remember doing a 'Beagle reboot' recently for some reason, and that must have used the old date/time. Typing the 'date' command in the Console, I saw that the date/time was incorrect.

    So, moments ago, I did a 'Beagle Power Off'. Then unplugged the 5V source, waited a bit (30 sec), then re-plugged in the power. After that, the 'date' command in the console shows today's date and current time.

    Sorry about the confusion. I appreciate you helping me out!

    73, Doug WW6D

Sign In or Register to comment.