1. Wsprdaemon
  2. Topics

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
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
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
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

wspr.png

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
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

noise.png

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

1 - 7 of 7