WSPR 22 m ISM Received Okay but Not being Spotted to the WSPRnet [fixed in v1.552]

va3romva3rom
edited August 2022 in WSPR, wsprdaemon, kiwirecorder

Well, the 22 m frequency changes is working (13.555400 MHz +/- 100 Hz) just fine. The KiwiSDR Status page tells me that I'm decoding 22 m WSPSR beacons, and I can see some of them in the Log, but nothing is showing up on the WSPRnet. For whatever reason, the KiwiSDR software isn't spotting any 22 m band WSPR decodes. Today, I had 46 decoded 22 m WSPR spots, according to the Status page but nada appeared on the WSPRnet server when I searched.

All the other WSPR bands (40, 30, 20, 15 and 10 m) that I'm decoding are being spotted just fine. Hopefully, jus a minor glitch and easy fix.

73,

Robert, VA3ROM

Comments

  • jksjks
    edited August 2022

    Lots of spots on wsprnet.org with received call "1X3ROM" (grid EN58). Nothing with that call as reporter though (filtered out?) Are you configured correctly?

    2022-08-06 00:20  1X3ROM  13.555464  -16  0  EN58  0.005  K5MO-1  FM05  1662  147  2


  • jksjks
    edited August 2022

    Oh wait, I see someone else using a "1X" prefix call. Is this so as not to use ham calls outside the ham bands? Must be.

    Is your reporter field set to "1X3ROM" when you upload spots for 22m? (and presumably not uploading spots for the ham bands using this reporter call). Are you using WSPR autorun or the WSPR extension from a browser connection? (it's important because the two use slightly different spot reporting mechanisms)

  • jksjks
    edited August 2022

    Well, I looked at this for a long, long time and I can't see anything wrong.

    I did find one other Kiwi that has uploaded 22m / 13.56 MHz spots in the last few days. I had to download the gigantic monthly .csv file because that's the only place the spot "version" field appears allowing you to tell it was uploaded from a Kiwi:

    xam:4560857149,1659626160,K3KQ,FM18dn,-19,13.555385,1X1EDJ,EM83,7,0,741,39,13,1.3 Kiwi,1
xam:4560864930,1659626400,K3KQ,FM18dn,-19,13.555385,1X1EDJ,EM83,7,0,741,39,13,1.3 Kiwi,1
xam:4560865015,1659626400,K3KQ,FM18dn,-20,13.555467,1X3ROM,EN58,7,0,1429,136,13,1.3 Kiwi,1
xam:4560871511,1659626520,K3KQ,FM18dn,-19,13.555466,1R4MNS,EN58,7,0,1429,136,13,1.3 Kiwi,1
xam:4560884695,1659626880,K3KQ,FM18dn,-20,13.555334,1X1EDJ,EM83,7,0,741,39,13,1.3 Kiwi,1
xam:4560890306,1659627000,K3KQ,FM18dn,-19,13.555415,1X3ROM,EN58,7,0,1429,136,13,1.3 Kiwi,1
xam:4560890462,1659627000,K3KQ,FM18dn,-21,13.555351,K3SIW,EN52ta,7,0,982,110,13,1.3 Kiwi,1
xam:4560894941,1659627120,K3KQ,FM18dn,-13,13.555415,1R4MN,EN58,7,0,1429,136,13,1.3 Kiwi,1
xam:4560895138,1659627120,K3KQ,FM18dn,-17,13.555333,1X1EDJ,EM83,7,0,741,39,13,1.3 Kiwi,1
xam:4560902893,1659627360,K3KQ,FM18dn,-16,13.555334,1X1EDJ,EM83,7,0,741,39,13,1.3 Kiwi,1
xam:4560910224,1659627600,K3KQ,FM18dn,-14,13.555334,1X1EDJ,EM83,7,1,741,39,13,1.3 Kiwi,1
xam:4560910241,1659627600,K3KQ,FM18dn,-15,13.555415,1X3ROM,EN58,7,1,1429,136,13,1.3 Kiwi,1
xam:4560915236,1659627720,K3KQ,FM18dn,-15,13.555415,1S4NNZ,EN58,7,0,1429,136,13,1.3 Kiwi,1
xam:4560919417,1659627840,K3KQ,FM18dn,-17,13.555335,1X1EDJ,EM83,7,0,741,39,13,1.3 Kiwi,1
xam:4560929168,1659628080,K3KQ,FM18dn,-18,13.555335,1X1EDJ,EM83,7,0,741,39,13,1.3 Kiwi,1
xam:4560934658,1659628200,K3KQ,FM18dn,-14,13.555416,1X3ROM,EN58,7,0,1429,136,13,1.3 Kiwi,1
xam:4560934754,1659628200,K3KQ,FM18dn,-24,13.555351,K3SIW,EN52ta,7,-1,982,110,13,1.3 Kiwi,1
xam:4560939799,1659628320,K3KQ,FM18dn,-21,13.555416,1T3NNY,EN58,7,0,1429,136,13,1.3 Kiwi,1
xam:4560939627,1659628320,K3KQ,FM18dn,-19,13.555334,1X1EDJ,EM83,7,0,741,39,13,1.3 Kiwi,1
xam:4560947837,1659628560,K3KQ,FM18dn,-19,13.555333,1X1EDJ,EM83,7,0,741,39,13,1.3 Kiwi,1

    So these are all from K3KQ which is not a public Kiwi as far as I can tell. I don't know if these spots are from WSPR autorun or the extension. Note that 1X3ROM is spotted a number of times. Also note 1.3 Kiwi at the end of each spot.

    Here is how they appear on the wsprnet.org spot search UI.

    Screen Shot 2022-08-06 at 5.46.31 PM.png


  • G8JNJG8JNJ

    It's a while since I used WSPR in earnest, but I think the WSPR net database has some basic filtering of the raw data to exclude obvious junk decodes and 'strange' callsigns.

    It may also possibly reject stuff on non-amateur frequencies.

    Regards,

    Martin

  • n6gnn6gn

    @jks Now that you've already downloaded the monthly tome I thought I'd mention that wspr.rocks also (mostly) reports version, can go back to the beginning of time (well, you know what I mean) and is blazingly fast. Here's a search of unique calls over the last 5 weeks:

    image.png


  • va3romva3rom

    I'm using my KiwiSDR and WSPR extension to receive WSPR signals (40, 30, 22, 20, 15, 10 m) as "VA3ROM".

    My "1X3ROM" remote telemetry-over-WSPR transmitter is only used on 22 m because Canadian Amateurs can't transmit out of band using their Amateur Radio callsigns. Everything I receive is being spotted to the WSPRnet except for any "0", "1" and "Q" prefixed calls, which are normally used by Amateur Radio ballooners to identify telemetry-over-WSPR packets. My 22 m decodes show up in the KiwiSDR Log i.e. "1N5QBA" but are not being spotted to the WSPRnet. Others, using WJST-X are spotting 22 m okay. It's just my KiwiSDR that seems to not do so.

    I'll use my FT857 and WSJT-X to monitor 22 m WSPR and see if it spots okay to the WSPRnet.

    Perhaps the KiwiSDR software has a problem with "0", "1" and "Q" callsign starting prefixes since they aren't assigned by the ITU? I say this only because I've yet to stream any balloon telemetry-over-WSPR data on any band using the KiwiSDR WSPR extension yet they are showing up in my KiwiSDR Log as being received. Has any other WSPR extension KiwiSDR user been streaming "0", "1", "Q" prefixed calls to the WSPRnet on say 20 m (usually band for telemetry-over-WSPR) Amateur Radio balloon flights? Perhaps if other KiwiSDR users could add select the ISM_13 WSPR extension and see if they are receiving and spotting to the WSPRnet that would really help.


    Thanks and 73,

    Robert

  • jksjks
    edited August 2022

    Perhaps if other KiwiSDR users could add select the ISM_13 WSPR extension and see if they are receiving and spotting to the WSPRnet that would really help.

    As shown by Glenn and myself above we have such a case, K3KQ. He used a Kiwi and successfully uploaded 22m spots, including 1X3ROM. So we know it works. From wspr.rocks: (thanks Glenn)

    wspr.rocks.22m.png

    So I don't know what to think. I checked the code and it looks fine. You can set the reporter field to be basically anything you want. This is why you see reporters in the database like "KPH", "SWLEM3", "K5MO-1" etc. Received calls must be of the form AANLLL, A = alphanumeric (A-Z 0-9), N = 0-9, L = A-Z, space. But this is the WSPR standard and the code used by the Kiwi is exactly from wsprd. And we know it works per the above..

    Let me add a selectable option to the admin page, WSPR tab to log each spot upload command sent to wsprnet.org. Maybe we can see a corrupted field or something which is causing the spot to be filtered out.

  • va3romva3rom

    Okay.

    I setup my FT857D and WJST-X as "VA3ROM" to monitor 22 m and lo and behold received and spotted these WSPR signals to the WSPRnet:

    1654 -29 2.0 13.555315 0 W8AC EN91 7 1006

    1658 -30 2.2 13.555315 0 W8AC EN91 7 1006

    1708 -24 1.3 13.555378 0 KA9SZX EN40 7 891

    These were "normal" Amateur Radio (US) callsigns. Didn't know that US Hams could use them to transmit out of band, but I guess they can.


    So I'll setup WJST-X using my alternate callsign and use the KiwiSDR as "VA3ROM" then I can compare the difference and see if it has something to do with "0", "1" and "Q" prefixed calls or not.


    Thanks for the addition. I was thinking about having something to indicate whether a WSPR signal was spotted to the WSPRnet or not.


    I know that I'm probably the only one monitoring 22 m so it's hard to track down the "problem".


    73

    Robert

  • va3romva3rom

    Well at least K3KQ and his Kiwi, which seems to work fine and mine doesn't!


    It does take me three or four reboots to get it to log onto my LAN (ethernet cable connected). So it's always been "finicky".

  • n8ooun8oou

    I used the wspr extension on my kiwi last night on 22m and it decoded and uploaded to wspernet.org as expected. Today I configured the kiwi to autorun wspr, and I see in the log that I am decoding on 22m, but not uploading to wsprnet.org. N8OOU is the reporting callsign, Kiwi v1.550.

    I am curently active on 22m, but never used my hamcall. Some US hams on 22m are switching away from their callsign.


    Mike N8OOU 73

  • jksjks

    Okay, pretty sure I found it. Fix in the next release.. 🙄

    Thanks everyone. Much appreciated.

  • jksjks

    Fixed in v1.552

  • va3romva3rom

    Update to the new v1.552 and nothing received by 22m WSPR autorun extension on my KiwiSDR.

    I'm using a 5-port antenna coupler and my FT857D + WSJT-X is decoding and spotting 22 m WSPR signals as "ROMSWL" but so far, the Kiwi 22m WSPR autorun extension is deaf. Both are being feed with the same antenna through the antenna coupler and you would think that if my FT875D AND WSJT-X are decoding and spotting 22 m WSPR signals then the 22m Kiwi autorun extension should do likewise? But Nada. Zip. Zilch. Other bands are decoding and spotting okay using the WSPR autorun extension for 40, 30, 20, 15 and 10.

    I turn off my AGC when decoding extremely weak signals such as you would find on the 22m band. Whether of not the WSPR autorun extensions does or not is not known to me.

    Aldo, in the WSPR extension startup Log I see this:

    Sun Aug  7 13:06:32 00:00:33.309 ..2.....   2      L WSPR autorun: instance=2 band_id=7 off=0.00 if=7039.35 tf=7040.10 df=7039.35 cf=7040.10 cfo=100
Sun Aug  7 13:06:32 00:00:33.317 ..23....    3     L WSPR autorun: instance=3 band_id=8 off=0.00 if=10139.45 tf=10140.20 df=10139.45 cf=10140.20 cfo=200
Sun Aug  7 13:06:32 00:00:33.329 ..234...     4    L WSPR autorun: instance=4 band_id=20 off=0.00 if=13554.65 tf=13555.40 df=13554.65 cf=13555.40 cfo=400
Sun Aug  7 13:06:33 00:00:33.347 ..2345..      5   L WSPR autorun: instance=5 band_id=9 off=0.00 if=14096.35 tf=14097.10 df=14096.35 cf=14097.10 cfo=100
Sun Aug  7 13:06:33 00:00:33.373 ..23456.       6  L WSPR autorun: instance=6 band_id=11 off=0.00 if=21095.35 tf=21096.10 df=21095.35 cf=21096.10 cfo=100
Sun Aug  7 13:06:33 00:00:33.409 ..234567        7 L WSPR autorun: instance=7 band_id=13 off=0.00 if=28125.35 tf=28126.10 df=28125.35 cf=28126.10 cfo=100


    What does "cfo" mean and why is is 100 (Hz?) for all the WSPR bands except 30m where it's 200 and then on 22m it's 400? One would think that since all the WSPR sub-bands are FSK center carrier +/- 100 Hz so shouldn't cfo always be 100?

    Will tune my Kiwi to 13553.9 kHz (SSB) and feed 22m audio into WJST-X and see if I can decode and spot 22m WSPR that way. This would at least tell me that something is still amiss with the 22m WSPR autorun extension settings.

    Now I really feel badly about starting this thread and causing all this work for you. Why I'm the only one having problems with the 22m WSPR autorun extension is a mystery to me.

    73,

    Robert

  • jksjks
    edited August 2022

    Now I really feel badly about starting this thread and causing all this work for you.

    Are you kidding? You helped me find a major, major bug. All Kiwis using WSPR autorun have not been successfully uploading ANY low power (< 10 dBm) spots prior to v1.551/552. Not on ANY band. That's an awful bug. I am extremely grateful to you for pointing that out. It would have likely gone completely unnoticed otherwise..

    Now, this doesn't explain why you're still having problems. We have confirmation now that the fix works (in general) because N8OOU is now uploading 22m spots using v1.552 autorun. We know it's autorun because the version tag at wspr.rocks says 1.4A Kiwi (this is new in v1.552). He's even spotting you now.

    From wspr.rocks:

    wspr.rocks.2.png


  • jksjks
    edited August 2022

    Try running 22m as the only autorun on your Kiwi. Running 6 of them is probably causing all the decoding to be starved for cpu cycles. You might be missing 22m decodes because of that. Although if you have a non-zero decode count in the connection list then the spots should be uploaded. But try just running the single autorun anyway as an experiment.

    "cfo" is "carrier frequency offset". 400 Hz for 22m is correct. The 22m carrier (not dial) freq is 13555.400, so the offset is 400. This is the offset number that appears in the middle of the WSPR spectrum display scale of WSJT-X and the Kiwi WSPR extension.

    You know you're running v1.552 for sure? It says that in, for example, the "stats" tab of a normal connection or the status tab of an admin connection?

  • va3romva3rom

    Thanks for the suggestions.

    The band was shutdown by that G2 geomagnetic storm on Sunday and it's recovered. I see that my FT857D and WJST-X have decoded and spotted six 22 m WSPR signals while the KiwiSDR WSPR autorun extension has decoded and spotted one. But at least it's receiving and spotting.

    I noticed that the Kiwi WSPR extension decoded down to -26 dB SNR while the FT857D + WJST-X 2.5.4 software is decoding down to -29 for the other five signals that ranged from -27 to -29 dB SNR. Both receiving system are running from one active antenna 5-port coupler so the antenna and feed line are common to both. Only the receiver hardware and software are different and I can monitor this to see if this stays constant between the two receiving systems.

    Have latest version v1.552 running and now that my 22 m WSPR autorun extension is being spotted at least for the one WSPR signal, I'll try your suggestion and shut down a few other WSPR autorun receivers. I think that they are also limited in the lowest SNR as compared to WJST-X 2.5.4. I've seen WSPR decodes as low as -32 dB SNR with it.

    Given the extreme power cap sub-5mW of 22 m, using the FT857D + WJST-X just monitoring 22 m may be a better option for extreme weak signal work, and I'll let the Kiwi handle the five other WPSR channels that I monitor since I don't want to give those up as it seems to work okay with the much stronger WSPR signals use on the regular ham bands.

    Thanks for all the help. One problem solved and I'll let you work on the other 99 or so more ;)

  • jksjks

    Glad it finally worked for you. The code from wsprd used in the Kiwi software is very old (circa 2016). So it's not surprising a recent version of WSJT-X does better. Also not a surprise a FT857D hears better than a Kiwi.

    Thanks again for helping find this important bug.

  • n6gnn6gn

    Don't immediately fault the Kiwi HW because the reported SNRs are different. At low levels SNR numbers are suspect (ref K1JT) and it is likely that the algorithm has changed between the extension's decoder and WSJT-X. If the noise floor is established by the incoming signal, if the Kiwi is seeing ~ >-145 dBm/Hz, then I suspect the actual SNR presented to the Kiwi's decoder is the same as to the Yaesu.

    No doubt the newest decoders are better, they are claimed to be, but I wouldn't immediately fault the Kiwi hardware. Other measurements that have been made, e.g. using kiwirecorder to extact audio to be decoded on equal decoders (wsprd) have shown equal performance if the external input is establishing the noise level.

Sign In or Register to comment.