use of kiwirecorder, kiwiwspr etc
I thought this subject needed it own subject rather than living in the bugs fixed thread,
http://forum.kiwisdr.com/discussion/1105/what-is-the-status-of-the-wspr-background-and-autostart-features-added-in-v1-181#latest
http://forum.kiwisdr.com/discussion/1105/what-is-the-status-of-the-wspr-background-and-autostart-features-added-in-v1-181#latest
Comments
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.
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 ;=)
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
curl -s ftp://ftp.swpc.noaa.gov/pub/latest/DSD.txt | awk 'END {print $(NF-11)}'
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 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.
I was trying to glance at it while at work, never a good move.
Thanks Rob.
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.
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)
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.