rrobinet

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.

I am currently running 6 instances of this command line script on a Raspberry Pi 3b+ at KPH, and it should also run on Max OSX.

To use it:

1) create a directory for it (e.g. /home/pi/kiwiwspr) and copy the attached kiwiwspr.sh into that directory
2) execute: "chmod +x kiwiwspr.sh"
3) execute ./kiwiwspr.sh -h

The program will guide you through the setup of the environment. It depends upon:

1) the 'bc' (Binary Calculator)
2) the kiwirecorder.py program
3) and WSJT-x. WSJT-x doesn't need to run, only the 'wsprd' command line application is used here.
4) Then you will need to edit the template configuration file 'kiwiwspr.conf' file created by kiwiwspr.sh to include the IP address(es) of your Kiwi(s)
5) The simplest way to run the program is to execute './kiwiwspr.sh -J a' (start all jobs)
./kiwiwspr.sh -j will display the status of all the jobs defined in kiwiwspr.conf
./kiwiwspr.sh -h attempts to describe all of the command line options, although I hope you will need to use only "-J a" an "-J z"

There are log files for each job in the /tmp/kiwi-captures/... directory tree if you want to look 'under the hood'

I expect that you will experience problems installing and running ?this problem, so don't hesitate to ask for help.

Here are the results of some further auto-wspr testing. My conclusion is that auto-wspr works well as long as you are not flooded with 20+ signals.

I have previously found that at KPH on 20M the Kiwi auto-wspr daemon runs out of CPU time in many 2 minute spot times before it can decode all of the spots. I'm not sure which version of the WSPR decoder SW is in the current Kiwi v1.195 SW, but I don't expect that the decode SW will be optimized for CPU performance anytime soon. ?

So at KPH I have turned of Kiwi 20M auto-wspr and been feeding Kiwi 20M audio to WSJT-x running on the Mac Air in the KPH rack. Since yesterday all of the KPH 20M spots have been recorded by that setup. Hopefully it will be a stable configuration, and I suspect I'll need to implement the same signal flow on 40M, 30M and perhaps other high WSPR traffic HF bands.

However I wondered if auto-wspr could be useful on bands with much less traffic. So last night I set up an audio feed from KPH to WSJT-x running on my Berkeley Mac which spotted as 'KPH/B'. That test showed some relatively small differences between the two spotters. Of the 293 unique spots logged by one or both of the systems, there were 59 spots which were only logged by one system, Of those 59 spots, 29 were unique to the auto-spotter and 32 were unique to WSJT-x.

Unfortunately I can't get a clean version of the comparison into this post

These results suggest to me that auto-wspr can be used on many bands at KPH. As we get more Kiwis at KPH I'll repeat this test on each band If I see little difference I'll use auto-wspr. I found this to be an encouraging result.