rrobinet

Version 1.1e has been in reliable service at a number of sites for a week. To summarize a clean installation:

1) create the directory /home/pi/ham/kiwiwspr

2) copy kiwiwspr-1-1e.sh to /home/pi/ham/kiwiwspr/kiwiwspr.sh

3) run "chmod +x /home/pi/ham/kiwiwspr/kiwiwspr.sh"

4) run: "/home/pi/ham/kiwiwspr/kiwiwspr.sh -h" until you are no longer prompted to install any of the following programs:
The program will prompt you to install kiwirecorder.py. Download it from https://github.com/jks-prv/kiwiclient/tree/jks-v0.1 to /home/pi/ham/kiwiwspr/kiwiclient-jks-v0.1
The program will prompt you in install WSJT-x from http://www.physics.princeton.edu/pulsar/K1JT/wsjtx.html
The program will prompt you to install 'bc' by running: 'sudo apt-get install bc'

5) Edit the prototype configuration file '/home/pi/ham/kiwiwspr/kiwiwspr.conf' created during step #4 to reflect:
a) The name for your Kiwi(s), their IP addresses and Grid locator
b) The schedule of WSPR bands for it to spot. Configure only hour '00:00' if you want the same configuration 24/7

6) run "./kiwiwspr.sh -j a" to start the capture jobs defined in your kiwiwspr.conf

7) print the status of your jobs by running "./kiwiwspr.sh -j s"

Once "./kiwiwspr.sh -j s" lists capture and decode daemons for each of your configured bands:

8) run "./kiwiwspr.sh -w a" to start the watchdog daemon which will every 2 minutes verify that your jobs are still running and execute the configuration changes defined in your kiwiwspr.conf
"./kiwiwspr.sh -w a" will also configure your Pi so the watchdog daemon runs every time your Pi is powered up or rebooted.

Finally, each job writes 200 Kbps of wav data to files in /tmp/kiwi-captures/... If that file tree is at its Pi default location on the microSD, this writing will significantly shorten the lifetime of the microSD. To avoid that wear, configure your Pi's /etc/fstab to make /tmp/kiwi-captures/ a ramdisk file system:

pi@PiKPH:~/ham/kiwiwspr $ tail -2 /etc/fstab
### For kwiwwspr.sh capture files
tmpfs /tmp/kiwi-captures tmpfs defaults,noatime,nosuid,size=100m 0 0
pi@PiKPH:~/ham/kiwiwspr

Version 1.1e has been in reliable service at a number of sites for a week. To summarize a clean installation:

1) create the directory /home/pi/ham/kiwiwspr

2) copy kiwiwspr-1-1e.sh to /home/pi/ham/kiwiwspr/kiwiwspr.sh

3) run "chmod +x /home/pi/ham/kiwiwspr/kiwiwspr.sh"

4) run: "/home/pi/ham/kiwiwspr/kiwiwspr.sh -h" until you are no longer prompted to install any of the following programs:
The program will prompt you to install kiwirecorder.py. Download it from https://github.com/jks-prv/kiwiclient/tree/jks-v0.1 to /home/pi/ham/kiwiwspr/kiwiclient-jks-v0.1
The program will prompt you in install WSJT-x from http://www.physics.princeton.edu/pulsar/K1JT/wsjtx.html
The program will prompt you to install 'bc' by running: 'sudo apt-get install bc'

5) Edit the prototype configuration file '/home/pi/ham/kiwiwspr/kiwiwspr.conf' created during step #4 to reflect:
a) The name for your Kiwi(s), their IP addresses and Grid locator
b) The schedule of WSPR bands for it to spot. Configure only hour '00:00' if you want the same configuration 24/7

6) run "./kiwiwspr.sh -j a" to start the capture jobs defined in your kiwiwspr.conf

7) print the status of your jobs by running "./kiwiwspr.sh -j s"

Once "./kiwiwspr.sh -j s" lists capture and decode daemons for each of your configured bands:

8) run "./kiwiwspr.sh -w a" to start the watchdog daemon which will every 2 minutes verify that your jobs are still running and execute the configuration changes defined in your kiwiwspr.conf
"./kiwiwspr.sh -w a" will also configure your Pi so the watchdog daemon runs every time your Pi is powered up or rebooted.

Finally, each job writes 200 Kbps of wav data to files in /tmp/kiwi-captures/... If that file tree is at its Pi default location on the microSD, this writing will significantly shorten the lifetime of the microSD. To avoid that wear, configure your Pi's /etc/fstab to make /tmp/kiwi-captures/ a ramdisk file system:

pi@PiKPH:~/ham/kiwiwspr $ tail -2 /etc/fstab
### For kwiwwspr.sh capture files
tmpfs /tmp/kiwi-captures tmpfs defaults,noatime,nosuid,size=100m 0 0
pi@PiKPH:~/ham/kiwiwspr

I run multiple kiwirecorder.py client sessions on one server. At KPH there are two servers, one a Raspberry PI 3b, while the second server is an odroid. Both servers experience the crashes/restarts at about the same irregular rate. Currently both clients are configured to run 11 client sessions on each server. On the Pi, 8 sessions go to Kiwi76 and 3 LF sessions to Kiwi72. On the odroid 8 sessions go to Kiwi75 and 3 sessions to Kiwi72. The crashes occur on both servers and were occurring when only the Pi clients were running. I have experimented with configuring the Pi to run 20 clients, 8 to Kiwi76, 8 to Kiwi75 and 3 to Kiwi72 and the crash frequency went up significantly to several times per hour. I have two beta sites running my code, one on an odroid and a second on a x86 Debian, and both those sites experience crashes, but at lower frequency due to, I believe, both running 8 or fewer clients.

I have just finished version 0.5d which adds support for a watchdog and scheduled band configuration changes.
It also incorporates many command line changes which I hope make it easier to use.
However it requires changes to the CAPTURE_JOBS[] array in the kwiconfig.conf file and you must add at least one WSPR_SCHEDULE[] entry.
It is running well at 3 sites, but as always save your current kwiwspr.sh and kwiwspr.conf file in case this new version doesn't work for you.
It is a very lightweight program and you can easily spot all 14 LF/MF/HF WSPR bands on a Raspberry Pi
I welcome comments and bug reports

I have implemented version 0.5c of kiwiwspr.sh which includes a watchdog daemon that checks the status of the kiwirecorder.py sessions each odd 2 minutes and restarts or performs scheduled configuration changes on them as needed. The watchdog log shows that one or more (and sometimes all) of them dead at random times. I will need to modify kiwiwspr.sh to save the error output of kiwirecorder.py, but looking at the restart times strongly suggests those restarts are happening at semi-random times. So they are unlikely generated by your update check. I'm sorry if I mislead you into a unneeded diagnostic task.