Rob - early (10 minutes in) it appears your ssh solution finally fixed both of my Atomic Pi's.  By now they usually would go into "rapid loop mode".  Thanks, this is a great improvement as I had to dedicate another Api to keep a session open IF after a reboot of an Api running wd, I at least once ssh'd in from another system and ran wdln. If I never log in remotely after a reboot, it was stable btw.
Wayne

Thanks to a suggestion from Bret KG7RDR, I learned that our 100% CPU bug is probably a symptom seen by many Linux systems since an update of Debian/Ubunut/RaspianOS last summer.  Bret said IT departments are working around that bug by ensuring there is always at least one ssh session connected to a server.  So I have added code to WD which spawns (or ensures) such a very lightweight ssh session is running from the WD server to itself.  You won't see that session listed by the linux 'w' command since it doesn't even run a login terminal, but it seems to do enough to fix our bug. 

With the help of Rick KK6PR I have just tested and checked in that band-aid.  That fix hasn't broken KFS, KPH, or KK6PR, but I don't think I can reliably test it at sites where have only RAC (WDE Remote Access Channel) connection to a server.

To test this fix, just 'git pull' and then execute 'wd -v'.  There is no need to restart a running WD unless you don't have (and want) this morning's checkins which restore ADC overload monitoring.
When you first run 'wdv' or other WD command, you probably will be prompted to type in 'yes' as shown below.  You will only be asked for that once.

Please report any installation or runtime problems.

Rob

pi@KPH-Pi4b-85:~/wsprdaemon $