new WSPR decoder in release v1.54

jksjks
in KiwiSDR Discussion
The v1.54 release adds the latest decoder from the WSPR-X application to the KiwiSDR WSPR extension.

To try it select "new" from the menu labeled "decoder" on the WSPR extension control panel. Make this selection before starting the decoding process, which is usually by clicking one of the band buttons.

The previous "old" decoder still exists and is selected by default. The new decoder is a work-in-progress and may have a few quirks. You will find it is much faster than the older one. It also supports type 2 and 3 WSPR messages which allows compound callsigns (prefix and/or suffix) and 6 character grid square locators.

As always, your feedback is appreciated.

Comments

  • G8JNJG8JNJ
    Hi John,

    Just tried the new decoder and it seems to work very well.

    Now I can leave the KiWi running indefinitely on the local connection, I'll monitor it for the rest of the day and report back.

    Any further thoughts about being able to run WSPR in the background when the SDR is not otherwise in use ?

    Regards,

    Martin
  • WA2ZKDWA2ZKD
    running new WSPR locally, I observed the server restart on its own, once after 30 or so mins. 
  • SWLJO43SWLJO43
    Yeah, the new one is extremly faster, than you John.
    A single WSPR new decoder is running and running.
    After starting a second WSPR new decoder, without anything to decode, it is runing and running.
    After starting a third  WSPR new decoder, the KiwiSDR is resetting after arround 30 minutes. :-(
    If i repeat the steps mentioned above,  this error occurs every time.
  • jksjks
    Okay, I'll look into that. I haven't done any stress testing yet myself.

  • WA2ZKDWA2ZKD
    I have a few halts of the new decoder but no more restarts like at 06030 today.  OLD seems OK, so just the new wspr code FWICT
  • KA7UKA7U
    leaving the new decoder running on 80 & 40. Should sample for just under 2 hours before timing out. So far some nice ZL and JA spots. 

    Ron - KA7U
  • WA2ZKDWA2ZKD
    1.55 seems more stable
  • WA2ZKDWA2ZKD
    enough stress and it still freezes however... I had 2 WSPR running and some non-wspr guests added enough were enough to freeze my wspr
  • jksjks
    Okay, I see now what the problem is. The callsign hash table used for the new type 2 and 3 messages is allocated in an unfortunate way for the limited physical memory (500 MB) of the Beagle. I'll release a fix for that today. Until then please only run one instance of the decoder to keep it from crashing.

    WA2ZKD
  • G8JNJG8JNJ
    edited February 2017
    Hi John,

    I had a report regarding WSPR from David, G0MRF, one of my SDR users.

    "Last night I left it running for a while on 630m and when I returned 10 mins later, I saw  5100km as a distance.  Hooray....Martin has nice antennas and a quiet site !!
    However, when I looked more closely, I noticed that no spot had been uploaded to WSPRnet and the stations callsign was missing?

    See attached screen grab.

    It looks to be WD2XSH/17 who was also transmitting a 6 digit locator (which is also rare) So doubtful if all that call and locator could fit in the available space anyway.

    So, not sure if this counts as 'extended WSPR' or if there is something else odd about the transmission."

    Regards,

    Martin - G8JNJ




    Attachments:
    https://forum.kiwisdr.com/uploads/Uploader/e2/dafcb77aa1bdb617f6235d2a99772f.png
  • jksjks
    I'm not an expert about the topic of WSPR "extended" messages, e.g. exactly when they are recognized as spots by wsprnet.org or how you enable them on the transmit side. However the details are on page 10 and 16-17 here: http://physics.princeton.edu/pulsar/K1JT/WSPR_3.0_User.pdf

    So a message showing "... FN42PB" is a type 3 containing a callsign hash code and a 6 character grid square (instead of the usual 4). But a type 1 or type 2 message associating a callsign for the hash code had not previously been received on this WSPR run. So the callsign field is shown as "...". The next time a type 3 is received the call should be shown if there was a intervening type 1 or 2 correctly received.

    Special note: unlike the WSPR-X app, right now the Kiwi code does not save the hash table in a Beagle file across multiple runs of the WSPR extension. So it does not incrementally build up information about callsign/hash associations. That simply means you will see more "..." entries during a run than you otherwise might.

  • G8JNJG8JNJ
    Hi John,

    Understood, that's pretty much what I thought, but I wanted to ask as you had previously mentioned the memory allocation issue.

    Regards,

    Martin - G8JNJ
Sign In or Register to comment.