Second build sold out. Message will appear here when store is ready for third build ordering.

use of kiwirecorder, kiwiwspr etc

«13

Comments

  • if I use this command: kiwiwspr -J z it kills the kiwiwspr tasks running on the second computer but the kiwirecorder.py sessions on the kiwi linger. How to stop those? I wanted to change freqs with a script on 2nd computer for unattended band changes.
  • edited July 2018
    It seems there are some zombi client daemons running on your linux client
    On your Pi/linux run 'killall kiwirecorder.py', or reboot it to clear those out.
    for me on a Pi, -J z ; -J kills and restarts all of the capture and decode deamons
    If zombie captures linger after a reboot, it may be that your OS differs from the Pi in how the daemon PIDs are reported.
    It would be hard for me to help you without access to your OS.
  • Thanks, I am cleaning up a few things here and will see if issue persists
  • So after a more permanent install of the Odroid-XU4/Ubuntu into my network, a reboot of it, and kiwi moving to 1.96, I do not see that lingering...
  • FWIW.... Rob's script etc. runs smoothly here. I added some band control via cron scripting to best use available channels on propagating bands. My 2 kiwi have different filter schemes so it helps with that also. I was going to add some antenna switching but now think I'll use an additional kiwi for each antenna. $+effort about equal for either scheme.
  • With John's addition of the 8 channel mode I see much less need for band hopping, so it may be quite a while before I get to that feature.
    I have enhanced the script with a '-w' == watchdog command and I gave that V0.2 to John for him to check in. However I can't find my script, so I'll ask John where it went ;=)
  • I forgot to do a git sync. It's there now: https://github.com/jks-prv/kiwiclient/tree/jks-v0.1
  • At KPH I have been running one 8 channel Kiwi from the script and logged 342 spots in the last hour. A second 8 channel Kiwi fed from the same RF splitter logged 131 spots in the last hour. So for users with excellent antennas they will get > 2 times the number of spots using a Pi to run my script.
  • Rob, which file changed?
  • jks-v0.1 branch: kwiclient/tools/kiwiwspr.sh
  • OK, I was seeing some deaths after many hours.... so that should help
  • Yes, I added the -w (watchdog) command to address any crashes in my code or the kiwirecord.py. Also, it restarts the dameons after a code upgrade.
  • Just put some new wheels, and amp on my fence antenna, giving this method a go.
    For some reason this use of BeagleBone SDR, Pi, Linux and the internet not to mention scrap metal wired to clever Bulgarian amplifiers makes the geek in me more happy than it rightly should.
    Thanks for the work Rob and others.
    Stu
  • For what its worth, here a piece of shell code that will run on the box running kiwiwspr.sh that will yield the current sunspot number. Even with eight channels you have to split up the day to cover all the bands, the number of splits and their limits will be a function of TOD, Season, and SSN.

    curl -s ftp://ftp.swpc.noaa.gov/pub/latest/DSD.txt | awk 'END {print $(NF-11)}'
  • Personally I need to get the script to restart the jobs reliably after a Kiwi update (yes I'm using -w) and improve my antenna setup before I worry about sunspots in this looming "maunder minimum 2.0".
  • if you're using -w, did you look with ps command to make sure the watchdog is running?
  • edited August 2018
    Watchdog not running, old script (didn't report -w unrecognised!), replaced script.
    Tried to use "kiwiwspr.sh -J a -w" no WD, tried "kiwiwspr.sh -w -J a" no WD.

    /home/pi/wspr/kiwiwspr.sh -W
    No Watchdog deaemon is running (well I never asked for "deaemon" cos that sounds super scary).

    I fink maybe some mistak kapitols
    -w => Display status of watchdog daemon
    -W => Spawn watchdog daemon which runs '-J a' every ${WATCHDOG_SLEEP_SECONDS} seconds
  • I'm sorry for the confusion. Capital J is the start/stop whereas lower case w is the 'start watchdog', while capital W is the 'get watchdog status' command. 'ps auxf' will show you all of your processes, including the watchdog when it is running.
    I want to run 'kiwiwspr.sh -w ' at Linux startup, but the old rc.local mechanism has been supplanted since Jessie OS. Implementing a command to configure this to run at startup is my next goal.
  • OK sorry, think I get it now, the spawn command and the status gave similar a response so I had assumed one was the other.
    I was trying to glance at it while at work, never a good move.

    Thanks Rob.
  • edited August 2018
    Rob didn't include 60M in his kiwiwspr script but I found it easy to add. Yesterday I logged ZS1YPJ there so it was worth the add.
  • the watchdog works as I frequently see a restart about 0600Z here on my 8 ch wspr only kiwi
  • I am working on version 0.4 which includes a number of functional enhancements to the watchdog mode and simplifications to the command line syntax.
    Your post reminded me that I had promised to add 60M to the frequency list, and that led me to this forum post: http://wsprnet.org/drupal/node/7352
    From that post I've learned there are dual frequencies on both the 80M and 60M bands, so I'm adding them to kiwiwspr's frequency list with these names:
    "80eu 3592.6"
    "60eu 5364.7"
    In the wsprnet database I see significant activity on both of those bands, so complete HF coverage seems to require 10 rx channels.
  • It's 14 wspr channels in total you could listen to on a kiwi: LF MF 160 80a 80b 60a 60b 40 30 20 17 15 12 10
    WA2ZKD
  • At KPH I have been listening to 11 channels using all of one HF Kiwi fed by a TCI-530 antenna and three channels of a Kiwi for LF/MF attached to a Marconi T antenna. When I finish V0.4 I will add those three missing HF bands using three channels on a second HF Kiwi. It will be interesting to see what we can pick up on those bands from the West Coast USA. In a couple of weeks we hope to start using a TCI-540 which is optimized for DX.
  • With my cron management of kiwiwspr.conf, I am listening to 14 bands now, just 8 at a time. Soon to be 14 concurrently.
  • without the watchdog, kiwiwspr.sh frequently stops about 0622Z. However with it running it makes a cron job to change bands by swapping kiwiwspr.ch tricky
  • The Kiwi runs an update task once a day to check for a new SW version and as part of that process terminates autowspr and kiwirecorder.py sessions for reasons only known to John. So that is one more reason for the need for a watchdog. My enhanced version with scheduled band changes is almost ready for testing
    WA2ZKDPowernumptyG0LUJ
  • Yeah, so I'm thinking of adding a bunch of yes/no options on the admin update tab.

    Like don't update if:
    Ordinary users are connected.
    WSPR auto-runs are active.
    TDoA service connections are active.
    kiwiclient/kiwirecorder connections are active.
    Other non Kiwi-UI connections are active (e.g. custom SNR measurement code that isn't kiwirecorder per se)
  • I don't think automatic updates = No is honored wrt to shutting down connections in current code.
  • edited August 2018
    If there's an issue with the update check killing sessions even if it's not going to update, I guess that's just a matter of fixing the check.

    But rather than a bunch of options for different kinds of sessions, I would suggest some heuristic like checking the age of the session. I think TDoA sessions and many others are usually rather short-lived, so they wouldn't be the ones that prevent the server from ever updating. Same with short-lived user sessions and recordings. Perhaps it would be better and simpler to consider the session age as the discriminant to decide whether they can be ended for update purposes, for example if the session is longer than one hour then it must be:
    - WSPR,
    - or someone AFK who left the session open,
    - or someone listening to something not so important that it can't suffer an interruption,
    - or someone who would feel comprehensive if their session was shut down after one hour.
Sign In or Register to comment.