Note: groups.io will be down for maintenance on Wednesday, October 5th, starting at 9AM Pacific Time (4PM Wednesday October 5, 2022 UTC), for approximately one hour.
- Sunrise errors
Re: Sunrise errors
toggle quoted messageShow quoted text
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.
On Thu, Jun 2, 2022 at 9:58 AM Bryan Klofas <bklofas@...
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!
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> <firstname.lastname@example.org
> <mailto:email@example.com>> wrote:
> 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.
> Gwyn G3ZIL
> Rob Robinett
> rob@... <mailto:rob@...>
> mobile: +1 650 218 8896
mobile: +1 650 218 8896
Join firstname.lastname@example.org to automatically receive all group messages.