Date   

WD 3.0.3 is now available and is the preferred and stable release

Rob Robinett
 

This morning I changed the version number of WD 3.0.2.6 to WD 3.0.3 and checked it in as the 'master' version.
WD 3.0.2.6 had been running on 32 beta sites, and now the 21 sites to which I have remote access are running 3.0.3.
I encourage the 11 sites still running 3.0.2.x to upgrade to 3.0.3.
There are also 20 sites running WD 2.x and I also encourage them to upgrade to 3.0.3.
If you have problems with an upgrade, 3.0 includes a configurable Remote Access feature which when enabled allows me to access your WD server without the need for you to make any modifications to your Wifi router or other Internet access equipment.

In addition to many, many bug fixes, WD 3.0 supports decoding of the FST4W transmission modes introduced in WSJT-x 2.3.0.

With 3.0 released, I will turn my software development efforts towards adding support for other SDRs like the RedPitaya, SDRPlay and AIRSpy.


WD Platform Chioces

Jim Lill
 

Although I have run wsprdaemon from the early days, before the merge feature was added., I think I only briefly used any RPi variant. At the time, I was running Odroid XU4 for other SBC projects so just built a WD system using one of those. With 8-core, 2G RAM, and 1.5+ GHz it served my 26 channels of wspr pretty well. I have two KiwiSDR/BBAI, each on its own antenna taking advantage of the merge feature. After having a fan failure, I started considering a fanless approach. Anticipating the added load of FST4 and other WD3 features, I also knew I'd need more processing power.  More MIPS without a fan could be done with a water-cooled CPU but I really wanted to keep my mains power budget low and keep my platform expense low too. My solution was the use of multiple Atomic-Pi which are X86 based, fanless, with 2G RAM, 4-core, running at 1.5GHz and 16G of on-board storage. They are about $50, you just need at add a PSU. I have 3 of them, one each for 40M, 30M, and 20M with the other bands sprinkled amongst them.   This also means no single point of failure and with some band schedule management, I can take one down for upgrade of the OS or other such task. Thus for less than $200 of platform hardware I have a fairly low power system that handles all my bands/receivers.

-Jim

WA2ZKD


Re: Sunrise errors

Gwyn Griffiths
 

Br yan
Appreciate the update - glad to read you got round the astral problem.

It's excellent that you have your Kiwi at a location above the Arctic Circle.
But that spectrum is truly 'pretty bad', though it looks as if you have several possible noise ingress methods to sort out, but can't be easy at a distance.

best wishes
Gwyn G3ZIL


Re: Sunrise errors

Bryan Klofas
 

Hey Rob and Gwyn--

Thanks for your help on this.

I ended up just modifying suntimes_astral2-2.py to just return "18:00 06:00", so got around that problem. I'm not changing frequencies based on sunrise/sunset, so this should be fine for now.

I did end up scrounging a small computer with a Celeron J1900, so I shouldn't need to worry about horsepower. But with all the noise the wspr binary only runs for a few seconds anyways. This site is online now with the callsign INUVIK.

I am using a W6LVP loop with LNA, so maybe some of that noise is common-mode problems. There is no ground on the linear power supply for the Bias-T. Interesting I didn't see any of these noise problems when I had it all set up for a week at my home in San Francisco, system performance was comparable to my 40/20/10 parallel/fan dipole on the roof.

I'll ship one of the T1-1+ transformers from N6GN up there soon, but it won't be installed for a while. Also I don't think my power source has a ground, only the computer power supply has a ground plug, so might have those problems also.

Attached is a spectrum display pic of 0-30 MHz. Pretty bad.

Thanks, have a great evening!
--
Bryan Klofas

On 6/2/22 10:36, Rob Robinett wrote:
Hi Bryan,
It appears that your site has a lot of switching power supply RFI.  I find it more helpful to look at the spectrum display, both zoomed in and 0-30 Mhz,  than just the waterfall.  Here is a closeup of a Kiwi at KFS where you can see both picket fence and zigzag RFI.  At KFS I have tracked that down to SWPSUs in a cell phone equipment shed, but at most sites we have see that RFI is introduced by common mode ingress through ground loops between the RF input ground and the Kiwi's DC input ground.  Such RFI can also be introduced through imbalances in the antenna system.
 If the antenna is balanced (e.g. dipole or loop), then a good starting test is to short the antenna connection terminals.  If the RFI doesn't go down by 10-20 dB, then the noise is not being sourced by then antenna but rather by the feedline and/or other components of the RF distribution system. Of course such a test isn't meaningful for unbalanced antennas.
Systems with LNAs at the antenna which are fed DC by a bias-t are especially vulnerable to ground loop induced RFI, since the ground of the bias-t power supply is connected to the RF input ground and thus forms a loop from there to the ground of the Kiwi's DC power supply.  In such a case feeding the bias-t with a battery will show if that biat-s DC power supply is a RFI source.
We have been supporting a Kiwi installation at VY0ERC up at Ellesmere Island at 82 north where RFI from the current antenna system renders it almost deaf.  Fixing such problems remotely is a real challenge.
Rob
Screen Shot 2022-06-02 at 10.22.58 AM.png
On Thu, Jun 2, 2022 at 9:58 AM Bryan Klofas <bklofas@... <mailto:bklofas@...>> wrote:
Hey Rob and Gwyn--
Yes, I'm trying to put a site in Inuvik, Canada. Everything is
installed, but the noise floor at this WISP site is absolutely
horrendous, see attached pic, so I'm not sure if this is going to work
or not. Spinning the loop around doesn't help.
I'll see if I can just rip out the sunrise/sunset stuff, I don't need
any complex scheduling at all, just turn it on a let it run 24/7.
Thanks, have a great afternoon!
--
Bryan Klofas
On 6/2/22 07:23, Rob Robinett wrote:
> I think that the only rx site which may encounter this is VY0ERC
which
> is currently offline.  Since this astral problem is encountered
only by
> WD users with sunrise/sunset schedules and there is only one site
which
> could encounter the problem, I think this is a low priority issue.
>
> As a reminder:   In WD 3.0 sunrise/sunset times are in the
timezone of
> the WD server
> Look at the file "hhmm.sched" to see how WD has translated
> the WSPR_SCHEDULE in the conf file to a HH:MM schedule.
> The file "suntimes" contains the sunrise/sunset times calculated
by the
> astral library
>
>
>
> On Wed, Jun 1, 2022 at 11:43 PM Gwyn Griffiths via groups.io
<http://groups.io>
> <http://groups.io <http://groups.io>>
<gxgriffiths@...
<mailto:virginmedia.com@groups.io>
> <mailto:virginmedia.com@groups.io
<mailto:virginmedia.com@groups.io>>> wrote:
>
>     Bryan
>
>     This is a known problem with the python astral library for
locations
>     with near to and higher latitudes than the Arctic and Antarctic
>     Circles depending on time of year when the sun does not set
or does
>     not rise.
>     The set location in your example is in the north of Canada's
>     Northwest territories - was that your intention?
>     If truly so, then Rob, we should discuss options, e.g.
wrapping the
>     astral program within one that has to check for applicable
time of
>     year and latitude before passing to astral.
>
>     regards
>     Gwyn G3ZIL
>
>
>
> --
> Rob Robinett
> AI6VN
> rob@... <mailto:rob@...> <mailto:rob@...
<mailto:rob@...>>
> mobile: +1 650 218 8896
>
--
Rob Robinett
AI6VN
rob@... <mailto:rob@...>
mobile: +1 650 218 8896


Re: Memory leak (Bullseye)

Andy Foad <andyfoad@...>
 

Thanks Rob!

73 de Andy G0FTD


Re: Memory leak (Bullseye)

Rob Robinett
 

Yes, that should build the newer Bash.
Gwynn G3ZIL performed that upgrade to his 64 bit Pi4 running bullseye and it has run fine for weeks.
I chose to install 64 bit Ubuntu on my Pi4. 


Re: Memory leak (Bullseye)

Andy Foad <andyfoad@...>
 

On Fri, May 27, 2022 at 03:39 PM, Rob Robinett wrote:
Gwyn has compiled Bash 5.1.16 on his bullseye Pi 3b and that fixes the problem.
Does this mean that you can use this source and compile in Bullseye ?

https://ftp.gnu.org/gnu/bash/bash-5.1.16.tar.gz

I presume that the procedure is to unzip that source into a folder on the Bullseye disk
and use the usual commands in the source code folder where you plonked it e.g /pi/bash-source/

mkdir build
cd build
cmake ..
make
sudo make install

73 de Andy G0FTD


Re: WD 3.0 users of scheduling should 'git pull'

Chris Mackerell
 

Thanks!

The zombies appear to have been successfully driven
out of my system with the new update 😁

Cheers, Chris

On 2022-06-04 08:11, Rob Robinett wrote:

This morning I made further refinements to WD 3.0.2.6 to address some 'zombie kiwirecorder' issues.
That newest 3.0.2.6 has been running cleanly on about 20 servers for 2-6 hours
So I would strongly encourage the dozen or so WD users who are running 3.0.2.6 to 'git pull' it and restart their WD service.
After startup run 'wd -l e' to watch for error lines.  You may see some or many lines soon after starting it, but after that you should see no error lines reported


Re: WD 3.0 users of scheduling should 'git pull'

Rob Robinett
 

This morning I made further refinements to WD 3.0.2.6 to address some 'zombie kiwirecorder' issues.
That newest 3.0.2.6 has been running cleanly on about 20 servers for 2-6 hours
So I would strongly encourage the dozen or so WD users who are running 3.0.2.6 to 'git pull' it and restart their WD service.
After startup run 'wd -l e' to watch for error lines.  You may see some or many lines soon after starting it, but after that you should see no error lines reported


Re: Kiwi connections not going away

Chris Mackerell
 

Yep. At least I have:

wsprdaemon      ALL=(ALL:ALL)   NOPASSWD:ALL

in /etc/sudoers. I assume that's what you mean?

I can login as wsprdaemon and do stuff like "sudo reboot"
without getting prompted for a password anyway.


If I shutdown things with "-z" all the strays get killed off
ok, so I thing that is ok. It's just during "normal operations"
that the kiwirecorders aren't getting killed.

Cheers, Chris


On 2022-06-03 16:31, Rob Robinett wrote:
Is your account set up for your user to 'auto-sudo'?

On Thu, Jun 2, 2022 at 9:29 PM Chris Mackerell <chris@...> wrote:
Hi Rob

I'm already on 3.0.2.6

It looks like only the WSPR decoding process is getting killed:

wsprdaemon@wsprdaemon:/tmp/wsprdaemon/recording.d/KIWI_1/10$ more decoding_daemon_kill_handler.log
Fri 03 Jun 2022 03:09:07 PM NZST: decoding_daemon_kill_handler() running in /tmp/wsprdaemon/recording.d/KIWI_1/10 with pid 941 i
s processing SIGTERM to stop decoding on KIWI_1,10
Fri 03 Jun 2022 03:09:07 PM NZST: Successful: 'kill_wav_recording_daemon running as pid 941 for KIWI_1 10 => 0

but there is still a kiwirecorder.py running and writing
.wav files to /tmp/wsprdaemon/recording.d/KIWI_1/10

   5464 ?        S      0:00 sudo nice --adjustment=-40 python3 -u /home/wsprdaemon/wsprdaemon/kiwiclient/kiwirecorder.py --freq=28124.6 --server-host=kiwisdr3.owdjim.gen.nz --server-port=8077 --OV --user=wsprdaemon_v3.0.2.6 --password=NULL --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60

Cheers, Chris

On 2022-06-03 16:11, Rob Robinett wrote:
Hi Chris,

Run 'git pull' to get the latest version of 3.0 after which  'wd -V' should print 3.0.2.6.

In beta testing I found that on busy servers the kiwirecord.py process which records the wav files was being interrupted by other programs and as a result there were corrupted wav files.  To address that problem I raised the program priority  of the kiwirecorder jobs, but they have to run as user 'root', so the schedule change must 'sudo kill ...' to them.  With that change those zombie kiwirecorder jobs should be killed.

There is still a lot of log file 'noise' associated with these changes and I am working to clean that up.

73,

Rob



--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


Re: Kiwi connections not going away

Rob Robinett
 

Is your account set up for your user to 'auto-sudo'?

On Thu, Jun 2, 2022 at 9:29 PM Chris Mackerell <chris@...> wrote:
Hi Rob

I'm already on 3.0.2.6

It looks like only the WSPR decoding process is getting killed:

wsprdaemon@wsprdaemon:/tmp/wsprdaemon/recording.d/KIWI_1/10$ more decoding_daemon_kill_handler.log
Fri 03 Jun 2022 03:09:07 PM NZST: decoding_daemon_kill_handler() running in /tmp/wsprdaemon/recording.d/KIWI_1/10 with pid 941 i
s processing SIGTERM to stop decoding on KIWI_1,10
Fri 03 Jun 2022 03:09:07 PM NZST: Successful: 'kill_wav_recording_daemon running as pid 941 for KIWI_1 10 => 0

but there is still a kiwirecorder.py running and writing
.wav files to /tmp/wsprdaemon/recording.d/KIWI_1/10

   5464 ?        S      0:00 sudo nice --adjustment=-40 python3 -u /home/wsprdaemon/wsprdaemon/kiwiclient/kiwirecorder.py --freq=28124.6 --server-host=kiwisdr3.owdjim.gen.nz --server-port=8077 --OV --user=wsprdaemon_v3.0.2.6 --password=NULL --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60

Cheers, Chris

On 2022-06-03 16:11, Rob Robinett wrote:
Hi Chris,

Run 'git pull' to get the latest version of 3.0 after which  'wd -V' should print 3.0.2.6.

In beta testing I found that on busy servers the kiwirecord.py process which records the wav files was being interrupted by other programs and as a result there were corrupted wav files.  To address that problem I raised the program priority  of the kiwirecorder jobs, but they have to run as user 'root', so the schedule change must 'sudo kill ...' to them.  With that change those zombie kiwirecorder jobs should be killed.

There is still a lot of log file 'noise' associated with these changes and I am working to clean that up.

73,

Rob



--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


Re: Kiwi connections not going away

Chris Mackerell
 

Hi Rob

I'm already on 3.0.2.6

It looks like only the WSPR decoding process is getting killed:

wsprdaemon@wsprdaemon:/tmp/wsprdaemon/recording.d/KIWI_1/10$ more decoding_daemon_kill_handler.log
Fri 03 Jun 2022 03:09:07 PM NZST: decoding_daemon_kill_handler() running in /tmp/wsprdaemon/recording.d/KIWI_1/10 with pid 941 i
s processing SIGTERM to stop decoding on KIWI_1,10
Fri 03 Jun 2022 03:09:07 PM NZST: Successful: 'kill_wav_recording_daemon running as pid 941 for KIWI_1 10 => 0

but there is still a kiwirecorder.py running and writing
.wav files to /tmp/wsprdaemon/recording.d/KIWI_1/10

   5464 ?        S      0:00 sudo nice --adjustment=-40 python3 -u /home/wsprdaemon/wsprdaemon/kiwiclient/kiwirecorder.py --freq=28124.6 --server-host=kiwisdr3.owdjim.gen.nz --server-port=8077 --OV --user=wsprdaemon_v3.0.2.6 --password=NULL --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60

Cheers, Chris

On 2022-06-03 16:11, Rob Robinett wrote:
Hi Chris,

Run 'git pull' to get the latest version of 3.0 after which  'wd -V' should print 3.0.2.6.

In beta testing I found that on busy servers the kiwirecord.py process which records the wav files was being interrupted by other programs and as a result there were corrupted wav files.  To address that problem I raised the program priority  of the kiwirecorder jobs, but they have to run as user 'root', so the schedule change must 'sudo kill ...' to them.  With that change those zombie kiwirecorder jobs should be killed.

There is still a lot of log file 'noise' associated with these changes and I am working to clean that up.

73,

Rob


WD 3.0 users of scheduling should 'git pull'

Rob Robinett
 

There were scheduling problems in 3.0.2.5 which are corrected in 3.0.2.6


Re: Kiwi connections not going away

Rob Robinett
 

Hi Chris,

Run 'git pull' to get the latest version of 3.0 after which  'wd -V' should print 3.0.2.6.

In beta testing I found that on busy servers the kiwirecord.py process which records the wav files was being interrupted by other programs and as a result there were corrupted wav files.  To address that problem I raised the program priority  of the kiwirecorder jobs, but they have to run as user 'root', so the schedule change must 'sudo kill ...' to them.  With that change those zombie kiwirecorder jobs should be killed.

There is still a lot of log file 'noise' associated with these changes and I am working to clean that up.

73,

Rob


Kiwi connections not going away

Chris Mackerell
 

Hi

I run a sliding schedule of bands that connect to my KiwiSDRs.

The connections to the Kiwis are not going away at the end
of a scheduled timeframe any more. New connections start all right,
but at the end they don't close completely.

"wd -s" doesn't show the jobs, but the Kiwi admin window still
shows connections. If I "kick" them from there they come
straight back up.

If I shut down wd I get lots of meaningless (to me anyway!)
messages about zombies running around the place.

This used to all work fine, but my Kiwis are now filling
up with unwanted connections at the wrong time of day.
I'm not 100% when this started going wrong, but suspect
it was around when v3 was merged into the master branch.

I've been running "wd -l e" but nothing appears there.

Running on Intel-based Ubuntu.

Any ideas?

Cheers, Chris

--
Chris Mackerell, 217 Sandy Bay-Marahau Road, Marahau
RD 2, Motueka 7197, New Zealand chris@...


Re: Sunrise errors

Rob Robinett
 

Hi Bryan,

It appears that your site has a lot of switching power supply RFI.  I find it more helpful to look at the spectrum display, both zoomed in and 0-30 Mhz,  than just the waterfall.  Here is a closeup of a Kiwi at KFS where you can see both picket fence and zigzag RFI.  At KFS I have tracked that down to SWPSUs in a cell phone equipment shed, but at most sites we have see that RFI is introduced by common mode ingress through ground loops between the RF input ground and the Kiwi's DC input ground.  Such RFI can also be introduced through imbalances in the antenna system. 

 If the antenna is balanced (e.g. dipole or loop), then a good starting test is to short the antenna connection terminals.  If the RFI doesn't go down by 10-20 dB, then the noise is not being sourced by then antenna but rather by the feedline and/or other components of the RF distribution system. Of course such a test isn't meaningful for unbalanced antennas.

Systems with LNAs at the antenna which are fed DC by a bias-t are especially vulnerable to ground loop induced RFI, since the ground of the bias-t power supply is connected to the RF input ground and thus forms a loop from there to the ground of the Kiwi's DC power supply.  In such a case feeding the bias-t with a battery will show if that biat-s DC power supply is a RFI source.

We have been supporting a Kiwi installation at VY0ERC up at Ellesmere Island at 82 north where RFI from the current antenna system renders it almost deaf.  Fixing such problems remotely is a real challenge.

Rob

Screen Shot 2022-06-02 at 10.22.58 AM.png
 

On Thu, Jun 2, 2022 at 9:58 AM Bryan Klofas <bklofas@...> wrote:
Hey Rob and Gwyn--

Yes, I'm trying to put a site in Inuvik, Canada. Everything is
installed, but the noise floor at this WISP site is absolutely
horrendous, see attached pic, so I'm not sure if this is going to work
or not. Spinning the loop around doesn't help.

I'll see if I can just rip out the sunrise/sunset stuff, I don't need
any complex scheduling at all, just turn it on a let it run 24/7.

Thanks, have a great afternoon!
--
Bryan Klofas

On 6/2/22 07:23, Rob Robinett wrote:
> I think that the only rx site which may encounter this is VY0ERC which
> is currently offline.  Since this astral problem is encountered only by
> WD users with sunrise/sunset schedules and there is only one site which
> could encounter the problem, I think this is a low priority issue.
>
> As a reminder:   In WD 3.0 sunrise/sunset times are in the timezone of
> the WD server
> Look at the file "hhmm.sched" to see how WD has translated
> the WSPR_SCHEDULE in the conf file to a HH:MM schedule.
> The file "suntimes" contains the sunrise/sunset times calculated by the
> astral library
>
>
>
> On Wed, Jun 1, 2022 at 11:43 PM Gwyn Griffiths via groups.io
> <http://groups.io> <gxgriffiths=virginmedia.com@groups.io
> <mailto:virginmedia.com@groups.io>> wrote:
>
>     Bryan
>
>     This is a known problem with the python astral library for locations
>     with near to and higher latitudes than the Arctic and Antarctic
>     Circles depending on time of year when the sun does not set or does
>     not rise.
>     The set location in your example is in the north of Canada's
>     Northwest territories - was that your intention?
>     If truly so, then Rob, we should discuss options, e.g. wrapping the
>     astral program within one that has to check for applicable time of
>     year and latitude before passing to astral.
>
>     regards
>     Gwyn G3ZIL
>
>
>
> --
> Rob Robinett
> AI6VN
> rob@... <mailto:rob@...>
> mobile: +1 650 218 8896
>







--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


Re: Sunrise errors

Bryan Klofas
 

Hey Rob and Gwyn--

Yes, I'm trying to put a site in Inuvik, Canada. Everything is installed, but the noise floor at this WISP site is absolutely horrendous, see attached pic, so I'm not sure if this is going to work or not. Spinning the loop around doesn't help.

I'll see if I can just rip out the sunrise/sunset stuff, I don't need any complex scheduling at all, just turn it on a let it run 24/7.

Thanks, have a great afternoon!
--
Bryan Klofas

On 6/2/22 07:23, Rob Robinett wrote:
I think that the only rx site which may encounter this is VY0ERC which is currently offline.  Since this astral problem is encountered only by WD users with sunrise/sunset schedules and there is only one site which could encounter the problem, I think this is a low priority issue.
As a reminder:   In WD 3.0 sunrise/sunset times are in the timezone of the WD server
Look at the file "hhmm.sched" to see how WD has translated the WSPR_SCHEDULE in the conf file to a HH:MM schedule.
The file "suntimes" contains the sunrise/sunset times calculated by the astral library
On Wed, Jun 1, 2022 at 11:43 PM Gwyn Griffiths via groups.io <http://groups.io> <gxgriffiths@... <mailto:virginmedia.com@groups.io>> wrote:
Bryan
This is a known problem with the python astral library for locations
with near to and higher latitudes than the Arctic and Antarctic
Circles depending on time of year when the sun does not set or does
not rise.
The set location in your example is in the north of Canada's
Northwest territories - was that your intention?
If truly so, then Rob, we should discuss options, e.g. wrapping the
astral program within one that has to check for applicable time of
year and latitude before passing to astral.
regards
Gwyn G3ZIL
--
Rob Robinett
AI6VN
rob@... <mailto:rob@...>
mobile: +1 650 218 8896


Re: Sunrise errors

Rob Robinett
 

I think that the only rx site which may encounter this is VY0ERC which is currently offline.  Since this astral problem is encountered only by WD users with sunrise/sunset schedules and there is only one site which could encounter the problem, I think this is a low priority issue.

As a reminder:   In WD 3.0 sunrise/sunset times are in the timezone of the WD server
Look at the file "hhmm.sched" to see how WD has translated the WSPR_SCHEDULE in the conf file to a HH:MM schedule.
The file "suntimes" contains the sunrise/sunset times calculated by the astral library



On Wed, Jun 1, 2022 at 11:43 PM Gwyn Griffiths via groups.io <gxgriffiths=virginmedia.com@groups.io> wrote:
Bryan

This is a known problem with the python astral library for locations with near to and higher latitudes than the Arctic and Antarctic Circles depending on time of year when the sun does not set or does not rise.
The set location in your example is in the north of Canada's Northwest territories - was that your intention?
If truly so, then Rob, we should discuss options, e.g. wrapping the astral program within one that has to check for applicable time of year and latitude before passing to astral.

regards
Gwyn G3ZIL



--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


Re: Sunrise errors

Gwyn Griffiths
 

Bryan

This is a known problem with the python astral library for locations with near to and higher latitudes than the Arctic and Antarctic Circles depending on time of year when the sun does not set or does not rise.
The set location in your example is in the north of Canada's Northwest territories - was that your intention?
If truly so, then Rob, we should discuss options, e.g. wrapping the astral program within one that has to check for applicable time of year and latitude before passing to astral.

regards
Gwyn G3ZIL


Sunrise errors

Bryan Klofas
 

Hey Rob--

Corner case: The sun is always up or down. From watchdog_daemon.log:

Thu 02 Jun 2022 05:05:01 UTC: watchdog_daemon() Starting in /home/wsprdaemon/wsprdaemon as pid 21929
Thu 02 Jun 2022 05:05:01 UTC: watchdog_daemon() Starting odd minute, do all watching functions
Spawned new upload_to_wsprnet_daemon job with PID '22163' and recorded that pid to '/home/wsprdaemon/wsprdaemon/uploads.d/wsprnet.d/spots.d/upload_to_wsprnet_daemon.pid' == 22163
Spawned new upload_to_wsprdaemon_daemon job with PID '22171' and recorded that pid to '/home/wsprdaemon/wsprdaemon/uploads.d/wsprdaemon.d/upload_to_wsprdaemon_daemon.pid' == 22171
Thu 02 Jun 2022 05:05:01 UTC: get_sunrise_sunset() Get sunrise/sunset for Maidenhead CP38di at long/lat -134 68
Thu 02 Jun 2022 05:05:03 UTC: get_astral_sun_times() ERROR: 'python3 /home/wsprdaemon/wsprdaemon/suntimes_astral2-2.py 68 -134 Etc/UTC' => 1

This is with the latest 3.0.2.5. Thoughts? Thanks!
--
Bryan Klofas

761 - 780 of 1670