release v1.45: improvements to WSPR and no more upload to wsprnet.org?

SWLJO43SWLJO43
edited May 2017 in Problems Now Fixed
image
Hi, i love to receive weak signals and to upload my spots to WSPR.
With the Version 1.45 it isnt possible anymore.

What can i do?

Greetings from Germany, Dirk (SWLJO43)

Comments

  • jksjks
    Hi Dirk,

    What do you mean it isn't possible anymore? Do you mean you think uploads are broken? Or somehow the feature has been removed?

    Uploading should still work. No changes were made to this. But, as usual, it is possible I have broken it, although I don't think so. I will now go double check..

  • jksjks
    Ah, I see what's wrong. Okay, I will have a fix in the v1.46 release later today (0200Z). Apologies..

  • SWLJO43SWLJO43
    Hi,

    sorry, my text was too short and my Image wasnt uploaded. :-( (https://goo.gl/photos/BvWpqvGEHP9VzxPy8)

    - uploads from kiwisdr to WSPR are broken

    cu Dirk
  • jksjks
    Just to mention what the improvements were since my documentation is not keeping up with the changes:

    The decoded WSPR callsign and grid fields are now clickable links to a lookup on qrz.com and a site that will show the grid on a map.
    The distance in km is computed between the "reporter grid" that is configured by the Kiwi administrator and the decoded grid.
    The decoded transmitter power field in dBm is also shown in units of Watts (W, mW, uW, ...)

  • SWLJO43SWLJO43
    Hello jks,

    thank you very much. The uploads from kiwisdr to WSPR are up and running again.

    Greetings Dirk

    My view in the WSPR viewer:
    UTC  dB   dT      Freq dF  Call   Grid    km  dBm
    1440 -12 -4.0 14.097103 -1 EA7EOO IM76 2199 37 (5.0 W)
    1442 -16 0.3 14.097125 0 5B4PRC KM64 2764 23 (200 mW)
    1444 -20 -0.9 14.097155 -1 K3RWR FM18 6493 37 (5.0 W)
    1446 -21 -0.8 14.097104 0 DL2FBI JO40 319 33 (2.0 W)
    1450 -7 -0.9 14.097123 -2 EA6ALL JM19 1624 23 (200 mW)
  • KA7UKA7U
    Yes John, Thank you very much. Nice set of new features for WSPR extension.
    Ron - KA7U
  • W5UXHW5UXH
    Curious:  I have been playing with the WSPR extension, very interesting.  With me being a 100% CW op for 56 years and ignorant of all digital modes, I wonder if it is reasonable for me to just leave WSPR running for a long time, with all the multiple spot uploads going to the web.  Might this be of interest to the WSPR ops out there?  Or is it just extra un-necessary data?
  • jksjks
    That's probably more of a question for the official WSPR group: http://wsprnet.org/drupal/
    My impression is that they take all loggings seriously and some people even do analysis on the database (which goes back to 2008!)

    There is an open feature request to allow the WSPR extension to be started automatically and run unattended (no browser connection necessary) which is in the spirit of collecting lots of spots.

    WA2ZKD
  • G8JNJG8JNJ
    Hi to W5UXH,

    Sure just leave it running 24/7 :-)

    There are plenty of low power 'beacon only' WSPR stations who would welcome being spotted consistently, plus having a much larger user base helps when using WSPR for antenna comparisons and propagation studies.

    However that being said, I'd suggest concentrating on the less popular WSPR bands such as LF / MF or 60, 12, 10 & 6M where the extra spots are more worthwhile than say 30m which is pretty much open world wide every day and has the most activity.

    Regards,

    Martin - G8JNJ
  • W5UXHW5UXH
    OK, Martin, thanks for that information.  I will do that.  Unfortunately my antenna is not very good, yours is much better!
  • davidsaintrubydavidsaintruby

    First off, I love the KIWISDR.  Capability to price ratio is great.  Hats off to all of you on the development side, including OpenWebRX.

    Just an observation with the latest rev - both 1.46 and .47.  I have noticed that wspr spots seem to fail to upload at approximately 6-7 hours of operation. Is it just me?


    best

    dsr


  • jksjks
    No, this has been reported before. I added some debug code a while back to help diagnose the problem. It doesn't seem to be consistently repeatable.

  • jksjks
    I just ran the WSPR extension for 9 hours with no problems. I used Firefox. What browser are you using? If you open your browsers Javascript console window you should see spot upload messages like this:

    WSPR SPOT Fri, 27 Jan 2017 15:52:22 GMT <1550 -24 -0.8  7.040174  0 JA5NVN PM74  37>

    Do these stop appearing when your spots fail to upload? Are you still getting decodes in the spot list of the WSPR extension?

  • jksjks
    In the v1.49 release I fixed a potential problem with some memory resources associated with a WSPR spot upload not being released. I ran WSPR for 14 hours with Firefox and the memory snapshot tool shows no memory leakage anymore. There was some before, but never enough for spots to cease uploading for me. I'd be interested to know what browser you're using.

  • SWLJO43SWLJO43
    Hello,

    i am using the EDGE-Browser without problems.
  • G8JNJG8JNJ
    Hi John and All,

    This may possibly be an issue associated with WSPRnet itself.

    There have been issues with uploads in the past where the WSPRnet server couldn't cope with the upload demand at various peak times.

    I some work was done by Bruce W1BW to try and fix this back in 2015 and 2016, but it may still be an issue from time to time as the number of reported spots continues to climb. 


    Do you trap any "Falure to connect to wsprnet" messages ?

    Regards,

    Martin - G8JNJ



     


  • jksjks
    I don't trap any failures posting to wsprnet.org because, as far as I can tell, it's impossible to do because of the various security limitations with same-origin / cross-domain posting. Second only to HTML CSS, I've had the most difficulty understanding how this works exactly. Just take a look at this post: http://stackoverflow.com/questions/298745/how-do-i-send-a-cross-domain-post-request-via-javascript

    In a nutshell, wsprnet.org doesn't return a "Access-Control-Allow-Origin: *" header which would allow me to use AJAX and examine the return status, so I must resort to the "iframe technique" to post spot uploads (and they properly don't want to do this because of the security implications on their end). But using iframes you can't look at the return status because it's in a different domain (cross-domain violation). So you're stuck. If anyone knows of a way around this I would love to know..

  • jksjks
    So one can ask the question "Well, how does the original WSPR app for the PC handle this problem?". And that question reminds me that the spot upload doesn't have to be done from the client (Kiwi user's) browser. It could be passed back to the Kiwi server and done from there where cross-domain restrictions don't apply.

    Looking at the WSPR app code shows something else. To avoid wsprnet.org getting hammered with spot uploads at the end of the two minute sampling period there is a random delay inside a 20 second window before upload. The Kiwi uploads generally take longer to occur because the Beagle is slower than a PC at decoding. But for strong signals it is possible that some spots are being lost because they are sent too close to the two minute mark (assuming there are older WSPR apps running that don't have the 20 second window mod). So I could add a delay.

  • davidsaintrubydavidsaintruby

    Here is my chrome log on a lock up



    WSPR STAT Tue, 31 Jan 2017 21:39:13 GMT
    wspr.js:530 WSPR SPOT Tue, 31 Jan 2017 21:40:03 GMT <2138 -23 -0.5 18.106009  1 W5OLF  DM79  30>
    wspr.js:530 WSPR SPOT Tue, 31 Jan 2017 21:42:03 GMT <2140 -20 -0.8 18.106119  0 K3RWR  FM18  37>
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 21:45:13 GMT
    wspr.js:530 WSPR SPOT Tue, 31 Jan 2017 21:46:03 GMT <2144 -20 -0.5 18.106038  0 W5OLF  DM79  30>
    wspr.js:530 WSPR SPOT Tue, 31 Jan 2017 21:46:08 GMT <2144 -20 -0.8 18.106121  0 K3RWR  FM18  37>
    kiwi_util.js:751 WS-CLOSE: FFT
    kiwi_util.js:751 WS-CLOSE: EXT
    kiwi_util.js:751 WS-CLOSE: AUD
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 21:51:13 GMT
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 21:57:13 GMT
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 22:03:13 GMT
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 22:09:13 GMT
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 22:15:13 GMT
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 22:21:13 GMT
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 22:27:13 GMT
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 22:33:13 GMT
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 22:39:13 GMT
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 22:45:13 GMT
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 22:51:13 GMT
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 22:57:13 GMT
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 23:03:13 GMT
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 23:09:13 GMT
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 23:15:13 GMT
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 23:21:13 GMT
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 23:27:13 GMT
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 23:33:13 GMT
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 23:39:13 GMT
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 23:45:13 GMT
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 23:51:13 GMT
    wspr.js:530 WSPR STAT Tue, 31 Jan 2017 23:57:13 GMT
    wspr.js:530 WSPR STAT Wed, 01 Feb 2017 00:03:13 GMT
    wspr.js:530 WSPR STAT Wed, 01 Feb 2017 00:09:13 GMT
    wspr.js:530 WSPR STAT Wed, 01 Feb 2017 00:15:13 GMT
    wspr.js:530 WSPR STAT Wed, 01 Feb 2017 00:21:13 GMT
    wspr.js:530 WSPR STAT Wed, 01 Feb 2017 00:27:13 GMT
    openwebrx.js:5078 WebSocket is already in CLOSING or CLOSED state.
    aud_send @ openwebrx.js:5078
    openwebrx.js:5091 WebSocket is already in CLOSING or CLOSED state.
    fft_send @ openwebrx.js:5091
    2openwebrx.js:5078 WebSocket is already in CLOSING or CLOSED state.
    aud_send @ openwebrx.js:5078
    openwebrx.js:5091 WebSocket is already in CLOSING or CLOSED state.
    fft_send @ openwebrx.js:5091
    2openwebrx.js:5078 WebSocket is already in CLOSING or CLOSED state.
    aud_send @ openwebrx.js:5078
    openwebrx.js:5091 WebSocket is already in CLOSING or CLOSED state.
    fft_send @ openwebrx.js:5091
    openwebrx.js:5078 WebSocket is already in CLOSING or CLOSED state.
    aud_send @ openwebrx.js:5078
    ext.js:16 WebSocket is already in CLOSING or CLOSED state.
    ext_send @ ext.js:16
    openwebrx.js:5091 WebSocket is already in CLOSING or CLOSED state.
    fft_send @ openwebrx.js:5091
    openwebrx.js:5078 WebSocket is already in CLOSING or CLOSED state.
    aud_send @ openwebrx.js:5078
    openwebrx.js:5091 WebSocket is already in CLOSING or CLOSED state.
    fft_send @ openwebrx.js:5091
    2openwebrx.js:5078 WebSocket is already in CLOSING or CLOSED state.
    aud_send @ openwebrx.js:5078
    openwebrx.js:5091 WebSocket is already in CLOSING or CLOSED state.
    fft_send @ openwebrx.js:5091
    3openwebrx.js:5078 WebSocket is already in CLOSING or CLOSED state.
    aud_send @ openwebrx.js:5078
    ext.js:16 WebSocket is already in CLOSING or CLOSED state.
    ext_send @ ext.js:16
    openwebrx.js:5091 WebSocket is already in CLOSING or CLOSED state.
    fft_send @ openwebrx.js:5091
    openwebrx.js:5078 WebSocket is already in CLOSING or CLOSED state.
    aud_send @ openwebrx.js:5078
    openwebrx.js:5091 WebSocket is already in CLOSING or CLOSED state.
    fft_send @ openwebrx.js:5091
    2openwebrx.js:5078 WebSocket is already in CLOSING or CLOSED state.
    aud_send @ openwebrx.js:5078
    openwebrx.js:5091 WebSocket is already in CLOSING or CLOSED state.
    fft_send @ openwebrx.js:5091
    2openwebrx.js:5078 WebSocket is already in CLOSING or CLOSED state.
    aud_send @ openwebrx.js:5078
    openwebrx.js:5091 WebSocket is already in CLOSING or CLOSED state.
    fft_send @ openwebrx.js:5091
    openwebrx.js:5078 WebSocket is already in CLOSING or CLOSED state.
    aud_send @ openwebrx.js:5078
    ext.js:16 WebSocket is already in CLOSING or CLOSED state.
    ext_send @ ext.js:16
    openwebrx.js:5091 WebSocket is already in CLOSING or CLOSED state.
    fft_send @ openwebrx.js:5091
    openwebrx.js:5078 WebSocket is already in CLOSING or CLOSED state.
    aud_send @ openwebrx.js:5078
    openwebrx.js:5091 WebSocket is already in CLOSING or CLOSED state.
    fft_send @ openwebrx.js:5091
    2openwebrx.js:5078 WebSocket is already in CLOSING or CLOSED state.
    aud_send @ openwebrx.js:5078
    openwebrx.js:5091 WebSocket is already in CLOSING or CLOSED state.
    fft_send @ openwebrx.js:5091
    3openwebrx.js:5078 WebSocket is already in CLOSING or CLOSED state.
    aud_send @ openwebrx.js:5078
    ext.js:16 WebSocket is already in CLOSING or CLOSED state.
    ext_send @ ext.js:16
    openwebrx.js:5091 WebSocket is already in CLOSING or CLOSED state.
    fft_send @ openwebrx.js:5091
    openwebrx.js:5078 WebSocket is already in CLOSING or CLOSED state.
    aud_send @ openwebrx.js:5078
    openwebrx.js:5091 WebSocket is already in CLOSING or CLOSED state.
    fft_send @ openwebrx.js:5091
    2openwebrx.js:5078 WebSocket is already in CLOSING or CLOSED state.
    aud_send @ openwebrx.js:5078
    openwebrx.js:5091 WebSocket is already in CLOSING or CLOSED state.
    fft_send @ openwebrx.js:5091
    2openwebrx.js:5078 WebSocket is already in CLOSING or CLOSED state.
    aud_send @ openwebrx.js:5078
    openwebrx.js:5091 WebSocket is already in CLOSING or CLOSED state.
    fft_send @ openwebrx.js:5091
    openwebrx.js:5078 WebSocket is already in CLOSING or CLOSED state.
    aud_send @ openwebrx.js:5078
    ext.js:16 WebSocket is already in CLOSING or CLOSED state.
    ext_send @ ext.js:16
    openwebrx.js:5091 WebSocket is already in CLOSING or CLOSED state.
    fft_send @ openwebrx.js:5091
    openwebrx.js:5078 WebSocket is already in CLOSING or CLOSED state.
    aud_send @ openwebrx.js:5078
    openwebrx.js:5091 WebSocket is already in CLOSING or CLOSED state.

  • jksjks
    When this happens is the rest of the interface still working? Audio playing? Waterfall and WSPR display scrolling?

  • davidsaintrubydavidsaintruby

    In prior versions (thinking 2+back) the UI was still working, but no spots were getting uploaded.  In the current revision, the whole UI in chrome is frozen.  That leads me to believe that some of the current changes around resource utilization, I-frames, etc. is "in the ballpark".   Just a reminder, this is with Chrome on windows 7.  I would be glad to do more debug logging if there are particular configuration items, browser plugins, etc. that help with the mission.

    Thanks again for a great product.

    Best


    dsr


  • WA2ZKDWA2ZKD
    Chrome on Linux works fine with v1.49
  • jksjks
    edited February 2017
    I had mixed results testing with a very crappy Celeron laptop running Windows 10. I could get Chrome and Firefox to fail using a Kiwi in Europe. But not with others including my own. The symptom is that the network connections (web sockets) simply get closed at some point. The javascript on the browser continues to run but with no network traffic there is no sound or waterfall. There are no other errors reported by the browser javascript console or server log. The first one to get closed is the sound (audio) socket. And there was a recent change to help garbage collect expired sound buffers. So that is very suspect.

    The v1.51 update going out at 0200Z today allows you to control the GC changes from the browser URL. You can force an update to v1.51 now by restarting your Kiwi server on the control tab of the admin page.

    All the GC changes are enabled by default. You can say things like:

    kiwisdr.local:8073/?gc_snd=0 disable GC changes for sound
    kiwisdr.local:8073/?gc=0&gc_wspr=1 disable all GC changes except enable those for WSPR
    kiwisdr.local:8073/?gc=0&gc_snd=1&gc_wspr=1 disable all GC changes except enable those for sound and WSPR

    When you open the page the browser javascript console will print a message saying exactly how they are set, e.g.
    GC: snd=0 wf=1 recv=1 wspr=0

    This is the complete list of GC control parameters. They *must* be given in the order listed below in the URL (i.e. ?gc=0&gc_wspr=1 *not* ?gc_wspr=1&gc=0)
    gc=0 disable all the following GC flags, re-enable them individually as required
    gc_snd=[01] GC in the sound code
    gc_wf=[01] GC in the waterfall code
    gc_recv=[01] GC of the message receive buffers
    gc_wspr=[01] GC of the WSPR spot reporting iframe & forms

Sign In or Register to comment.