What is the status of the WSPR background and autostart features? [added in v1.181]

rrobinetrrobinet
edited April 2018 in Problems Now Fixed
I see them listed on the Bug/Wish List page as a higher priority but no indication of in test  nor checkins in github.
I have found that I cannot keep browser-initiated WSPR sessions running for more than a few days, even when the browser and Kiwi are wired to the same switch.
So I am trying to decide if I should invest time in a multiple Rasperbrry Pi + SDRPlay solution for a multiband WSPR receiver appliance.
The Kiwi seems a much better (and cheaper!) solution, so I would rather invest time in advancing that aspect of Kiwi functionity.
«13

Comments

  • jksjks
    I have something beginning to work now. It's a bit primitive, but it gets the job done. After I do more testing I'll arrange for you to give it a try.

    WA2ZKDLX1DQ
  • bbachmannbbachmann
    sounds interesting :-)

  • rrobinetrrobinet
    If my interest represents the larger WSPR community, then I would expect that many of the spotters on wsprnet.org would be interested in deploying kiwis as dedicated WSPR spotting stations.  The 'background mode' is not of high importance to me as I just want a receiver dedicated to WSPR spotting running on each band 24/7/365.  Would dedicating the kiwi to WSPR allow more than 4 simultaneous bands to be scanned? There are at least 10 WSPR bands below 30 Mhz.
  • jksjks
    No. Just because you're WSPR spotting it doesn't take any less resources than normal listening. So the 4 channel limit still applies.

  • jksjks
    Okay, I just pushed v1.180  Reboot to get it now ahead of the auto update later today.

    I think things are working pretty well. On the "extensions" tab of the admin page select the WSPR menu item on the left to configure the autorun feature.

  • jksjks
    edited April 2018
    And now there is a v1.181

    You only have to do the following if you are running v1.180 and have WSPR autorun configured.
    This shouldn't effect very many people. Sorry about that!

    If you have configured WSPR autorun with v1.180 then to receive any further updates going forward you will have to manually force an update to v1.181
    This is because the update process is postponed whenever the Kiwi has a user connection. And prior to the fix in v1.181 a WSPR autorun connection counts as a user connection.

    To fix simply go to the admin "update" tab and click the "build now" button. This will manually force the update to v1.181  When the Kiwi restarts after the build the WSPR autorun will start as usual.

  • rrobinetrrobinet
    I upgraded directly to 181 and then configured all four channels for backbround WSPR mode.  Unfortunately the kiwid is now crashing and restarting as you can see from /var/log/syslog:

    Apr 23 04:52:23 kiwisdr kiwid[4850]: Starting kiwid
    Apr 23 04:52:24 kiwisdr kiwid[4850]: Start kiwid: OK
    Apr 23 04:52:24 kiwisdr kiwid[4850]: Mon Apr 23 04:52:24 UTC 2018
    Apr 23 04:52:24 kiwisdr kiwid: 00:00:00.845 ....      KiwiSDR v1.181 --------------------------------------------------------------------
    Apr 23 04:52:24 kiwisdr kiwid: 00:00:00.849 ....      compiled: Apr 23 2018 04:34:09
    Apr 23 04:52:24 kiwisdr kiwid: 00:00:00.851 ....      -debian 8
    Apr 23 04:52:24 kiwisdr kiwid: 00:00:00.851 ....      /etc/debian_version 8.5
    Apr 23 04:52:24 kiwisdr kiwid: 00:00:00.851 ....      background mode: delaying start 30 secs...
    Apr 23 04:52:54 kiwisdr kiwid: 00:00:30.888 ....      reading configuration from file /root/kiwi.config/kiwi.json: 139 tokens
    Apr 23 04:52:54 kiwisdr rsyslogd-2007: action 'action 17' suspended, next retry is Mon Apr 23 04:53:24 2018 [try http://www.rsyslog.com/e/2007 ]
    Apr 23 04:52:54 kiwisdr kiwid: 00:00:30.893 ....      reading configuration from file /root/kiwi.config/admin.json: 77 tokens
    Apr 23 04:52:54 kiwisdr kiwid: 00:00:31.280 ....      serial number from EEPROM: 1919
    Apr 23 04:52:54 kiwisdr kiwid: 00:00:31.402 ....      reading configuration from file /root/kiwi.config/dx.json: 7052 tokens
    Apr 23 04:52:54 kiwisdr kiwid: 00:00:31.405 ....      883 dx entries
    Apr 23 04:52:54 kiwisdr kiwid: 00:00:31.417 ....      listening on default port 8073/8073 for "openwebrx"
    Apr 23 04:52:54 kiwisdr kiwid: 00:00:31.421 ....      webserver for "openwebrx" on port [::]:8073
    Apr 23 04:52:55 kiwisdr kiwid: 00:00:31.653 ....      ### using SPI_DEV
    Apr 23 04:52:56 kiwisdr kiwid: 00:00:32.818 ....      FPGA version 1
    Apr 23 04:52:56 kiwisdr kiwid: 00:00:33.278 ....      using DC_offsets: I -0.020000 Q -0.020000
    Apr 23 04:52:57 kiwisdr systemd[1]: kiwid.service: main process exited, code=dumped, status=11/SEGV
    Apr 23 04:52:57 kiwisdr kiwid[4862]: DEBIAN 8
    Apr 23 04:52:57 kiwisdr kiwid[4862]: USE_SPIDEV
    Apr 23 04:52:57 kiwisdr kiwid[4862]: LOAD_SPI = no
    Apr 23 04:52:57 kiwisdr kiwid[4862]: Stopping kiwid:
    Apr 23 04:52:57 kiwisdr systemd[1]: Unit kiwid.service entered failed state.
    Apr 23 04:53:07 kiwisdr kiwid[4876]: DEBIAN 8
    Apr 23 04:53:07 kiwisdr kiwid[4876]: USE_SPIDEV
    Apr 23 04:53:07 kiwisdr kiwid[4876]: LOAD_SPI = no
    Apr 23 04:53:07 kiwisdr kiwid[4876]: Starting kiwid
    .....


    I can reboot the kiwi but hesitate because it is 2500 miles away.  What do your suggest?  I can open a port for you to get ssh access to the kiwi if you want.
    Thanks

  • jksjks
    I have no idea why it would be segfault-ing at that particular point.
    Yes, if I could get ssh access that would be a big help. Thanks.

  • rrobinetrrobinet
    I just emailed you ssh login details.  Let me know if you need more help
  • G8JNJG8JNJ
    Hi John,

    This is great. 

    Hopefully at some point it can be made to auto switch and run in the background only when spare receivers are available for use (or not all fully being used by others).

    In the meantime in order to make the best use of just one (or possibly more) receiver. Would it be possible to add a coordinated band hopping option to the WSPR menu ?


    Perhaps individual bands could be selected for inclusion in the sequence, if folks don't want to have them all enabled ?

    Regards,

    Martin - G8JNJ
  • WA2ZKDWA2ZKD
    if you could command it via a Linux shell script, you could use cron to select which bands via TOD
  • jksjks
    Okay, fixed. There was an interaction between autorun mode and having user connections disabled.
    Today's v1.183 update will fix this and the lock bug problem from yesterday.

  • rrobinetrrobinet
    edited April 2018
    This is great.

    My 4 configured autorun WSPR sessions are running, but a normal user cannot access the kiwi and I get:

    Sorry, the KiwiSDR server is too busy right now (4 users max). 
    Please check sdr.hu for more KiwiSDR receivers available world-wide.

    Did you plan to have a WSPR configuration option that the autorun session terminated each time an active user logs on?  That is the only feature needed for WSPR perfection. 

    I changed the config to 3 autoruns and watched two logins.  3 minutes after the second user logged off the kiwid PANCed and restartted:

    Apr 24 03:33:37 kiwisdr kiwid: 00:00:58.735 0123 [08] PWD admin config pwd set TRUE, auto-login TRUE
    Apr 24 03:38:10 kiwisdr kiwid: 00:05:31.796 0123      WSPR DECODE:  UTC  dB   dT      Freq dF  Call   Grid    km  dBm
    Apr 24 03:38:10 kiwisdr rsyslogd-2007: action 'action 17' suspended, next retry is Tue Apr 24 03:39:40 2018 [try http://www.rsyslog.com/e/2007 ]
    Apr 24 03:38:10 kiwisdr kiwid: 00:05:31.800 0123      WSPR DECODE: 0336 -16  0.1 10.140198  0  K0DSP  EN10 12374   30 (1.0 W)
    Apr 24 03:40:06 kiwisdr kiwid: 00:07:28.170 0123      WSPR DECODE: 0338  -6  0.2 10.140246 -3  KF9KV  EN52 13062   37 (5.0 W)
    Apr 24 03:40:06 kiwisdr rsyslogd-2007: action 'action 17' suspended, next retry is Tue Apr 24 03:41:36 2018 [try http://www.rsyslog.com/e/2007 ]
    Apr 24 03:40:08 kiwisdr kiwid: 00:07:30.497 0123      WSPR DECODE: 0338 -18  0.2  7.040079  0  KF6I   DM13 10498   40 (10 W)
    Apr 24 03:40:12 kiwisdr kiwid: 00:07:34.383 0123      WSPR DECODE: 0338 -13  0.4 10.140263  0  WA7IJV CN85 11062   27 (501 mW)
    Apr 24 03:40:13 kiwisdr kiwid: 00:07:34.900 0123      WSPR DECODE: 0338 -24  0.2  7.040031  0  K6MCS  CM98 10625   37 (5.0 W)
    Apr 24 03:40:35 kiwisdr kiwid: 00:07:56.676 0123    3 14011.78 kHz  cw z9  "188.226.41.179" Yekaterinburg, Russia (LEAVING after 0:07:16)
    Apr 24 03:41:39 kiwisdr kiwid: 00:09:00.670 0123    3  7160.00 kHz lsb z0  "88.130.46.188" Berlin, Germany (ARRIVED)
    Apr 24 03:41:39 kiwisdr rsyslogd-2007: action 'action 17' suspended, next retry is Tue Apr 24 03:43:09 2018 [try http://www.rsyslog.com/e/2007 ]
    Apr 24 03:42:04 kiwisdr kiwid: 00:09:26.434 012.    3  7160.00 kHz lsb z0  "88.130.46.188" Berlin, Germany (LEAVING after 0:00:37)
    Apr 24 03:42:07 kiwisdr kiwid: 00:09:29.191 012.      WSPR DECODE: 0340 -17  1.0  7.040071 -1  W7AGJ  CN87 11220   37 (5.0 W)
    Apr 24 03:42:11 kiwisdr kiwid: 00:09:32.614 012.      WSPR DECODE: 0340 -23  0.4  7.040112 -1  N5CEY  EL16 11504   30 (1.0 W)
    Apr 24 03:42:26 kiwisdr kiwid: 00:09:48.426 012.      WSPR DECODE: 0340 -26  0.2 10.140183  0  VE6EGN DO23 12086   27 (501 mW)
    Apr 24 03:44:04 kiwisdr kiwid: 00:11:26.071 012.      WSPR DECODE:  UTC  dB   dT      Freq dF  Call   Grid    km  dBm
    Apr 24 03:44:04 kiwisdr rsyslogd-2007: action 'action 17' suspended, next retry is Tue Apr 24 03:45:34 2018 [try http://www.rsyslog.com/e/2007 ]
    Apr 24 03:44:04 kiwisdr kiwid: 00:11:26.076 012.      WSPR DECODE: 0342 -16  0.2 10.140105  0  W0ZQ   EN34 12881   37 (5.0 W)
    Apr 24 03:44:05 kiwisdr kiwid: 00:11:27.491 012.      WSPR DECODE: 0342 -23  0.7  7.040097  0  K6SRO  CM88 10503   37 (5.0 W)
    Apr 24 03:44:10 kiwisdr kiwid: PANIC: "NZOMBIES" (support/non_block.c, line 100)
    Apr 24 03:44:11 kiwisdr systemd[1]: kiwid.service: main process exited, code=exited, status=255/n/a
    Apr 24 03:44:11 kiwisdr kiwid[15955]: DEBIAN 8


    Unfortunately even with 3 autorun sessions the kiwid PANICs after about 8 minutes of operation.  
    PANICs every 12-15 minutes with two autorun sassions
    PANICed after 47 minutes with one autorun session
    No PANICs after several hours when no autorun sessions were configured
    ...
  • jksjks
    edited April 2018
    Sorry (for those of you old enough: )
    Fix coming later today.

    k5mo
  • rrobinetrrobinet
    edited April 2018
    It looks like v1.184 fixed the PANICs.  Both of my Kiwis have run for 5 hours without restarting, one with 3 WSPR sessions, the other with none.
    One small bug:  the WSPR km field printed out  for each spot in /var/log/syslog is not correct.  It looks like the km from ZL, not my KH6  QTH.  The km for those spots in wsprnet.org have the correct distance.
    Thanks!
  • jksjks
    Good catch. I had hardwired my grid for the distance calculation during initial testing before the reporter grid was available. I made a fix on the Maui Kiwi and it seems okay now.

  • rrobinetrrobinet
    I have been successfully running 184 on both the Maui and Berkeley kiwis, so I am ready to declare this standalone WSPR reporting feature completed and tested.
    It is my impression that the structure of your code will make it difficult to enhance this feature to allow active users to preempt these sessions without a kiwi service restart.
  • n6gnn6gn
    I really like the changes. It allows my completely standalone kiwi (once I add batteries) to power up spotting WSPR into the database if I have a WiFi connection.  This is of great interest to me because I can then use a balloon or quadcopter to support kiwi+active dipole at altitude, measuring SNR as I go.  I think this height dependence isn't fully appreciated, particularly at LF and MF where the ground essentially acts as a shield and keeps not only E field (signal) but also SNR below what it is at elevation. I have almost everything I need to measure this once I attach an appropriate balloon.
    I do see one issue, I think.  If one has the time out feature invoked, the autostarted WSPR receivers disappear.  Can the a field be added to include a password so that the WSPR receivers can run continuously while any other users have normal access control?

    Good job!
    Glenn n6gn
  • n6gnn6gn
    Not sure yet that it is a password timeout problem.  Things go away after a few minutes. Maybe inactivity or a crash. Cause still TBD.
    Glenn n6gn
  • rrobinetrrobinet
    My Berekely kiwi with two autorun session has been running flawlessly for 16 hours.
    My Maui kiwi has been running for 8 hours since John upgraded the SW to put the correct Km distance in the WSPR /var/log/syslog entires
  • jksjks
    @Glenn: It's a bug. Being fixed in today's update.

    n6gn
  • rrobinetrrobinet
    In addition to running out of CPU time on busy bands, it is my impression that auto-wspr misses the weaker of two signals which are only a few hertz apart.

    What is the version of the WSPR decode library? I see your sources are dated 2015 and I thought there was a recent upgrade to that library in WSJT-x 1.8.0, but I am lost trying to find the WSJT-x source repository.
  • jksjks
    The last update to the Kiwi WSPR code was done in February 2017 and came from https://github.com/k9an/wsprcan This was the last version of the relatively simple standalone K9AN code in November 2015 before it was merged into WSJT.

    The WSJT/WSPR-X etc. codebase is a complete nightmare and there is no way I'm going to spend any time trying to unravel that stuff. If someone wants to do it and contribute a working, debugged and tested update to the existing Kiwi WSPR code that's fine.
  • G8JNJG8JNJ
    Hi John,

    Also be aware that there is some controversy regarding the frequencies used for WSPR on 80m.

    "with WSJT-X v1.8 we intend to correct an anomaly that has existed for a long time in that Japanese amateur radio operators have no privileges for the frequencies commonly used for WSPR, JT65 and JT9. The current frequencies (USB dial frequency) are:

    WSPR 3.592600 MHz, JT65 3.576000 MHz, JT9 3.578000 MHz

    because we strongly prefer that WSPR and JT mode frequencies are globally coordinated where possible, the proposed new frequencies are:

    WSPR 3.568600 MHz, JT65 3.570000 MHz, JT9 3.572000 MHz, FT8 3.573000 MHz

    This places the conventional 200 Hz wide WSPR sub-band (centred around +1500 Hz audio offset) into the lower 200 Hz the JT65 sub-band. The lower 200 Hz of the JT65 sub-band is not used due to SSB filter roll off."

    Most folks are sticking with the original allocations, but you may wish to include the new(ish) proposed frequency in the KiWi WSPR decoder list of frequencies.

    Regards,

    Martin - G8JNJ
    WA2ZKD
  • jksjks
    We already have this. See "80m_JA" and "60m_EU" in the WSPR control panel band menu.
  • G8JNJG8JNJ
    Hi John,

    Ah OK, I hadn't realised the significance of "80m_JA" as my understanding was that this is a new IARU proposal affecting all regions.

    Regards,

    Martin
  • rrobinetrrobinet
    I appreciate the complexity of being forced to regularly update the wsprd code into the Kiwi.

    However the current autorun code extracts only 1/2 of the signals that WSJT-x v1.9.1, so on 20M I am running a broswer on my Mac and feeding audio to WSJT-x.
    This is an awkward and fragile SW architecture and I am looking at how to replace it.

    One approach is to run the Python kiwirecorder on the Mac/Pi/.. and capture the IQ data to a file and then execute the wsprd app included in WSJT-x, but that would force me to synchronize time between the two.

    As an alternative, I am studying writing a Kiwi extension modeled on the auto-wspr extension which simply writes the 2 minutes of IQ samples to a file on the Kiwi and then each 2 minutes it transfers that file to a PC/Mac/Linux server for processing by the WSJT-x sw on that machine. Such an approach would disconnect the Kiwi-PC connection from time-critical functions and also free the Kiwi from a need future changes/enhancements to the WSPR processing code base.

    Does writing such an enhancement seem a useful approach to solving my problem?
  • WA2ZKDWA2ZKD
    How many instances wspr-autorun are you running on the kiwi simultaneously?
  • rrobinetrrobinet
    I run two or 3. on LF/MF where there are few signals the autorun works OK. But on 40M the Kiwi frequently runs out of time before extracting all of the signals.
  • WA2ZKDWA2ZKD
    I have 2 kiwi. I run 40 wspr on 1 channel of the guest box, and 4 other wspr on the second. I cron band changes on that one. Do you find that 40 suffers even when it is the only activity on a single kiwi?
Sign In or Register to comment.