Date   

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


Re: External USB Stick/Disk

Rob Robinett
 

WD stores all of its temporary files in the ram disk /tmp/wsprdaemon.  Only important files which you wouldn't want to be lost in an unexpected power off event (like the cache of spots waiting to uploaded) are stored on the microSD
Storing on an external USB drive would be slow, so much so that configurations with many channels might not run and would in any case soon wear out a flash drive.


External USB Stick/Disk

whartmuth@...
 

A Raspberry Pi runs from SD-Card. so It might be a good idea when /tmp/wsprdaemon is not on the same SD-Card.
Is there an easy way to convince wsprdaemon to use an external USB-Stick or disk to store the files?

I am using a Raspberry Pi 4 with 4Gb memory and bullseye.

Thank you, vy73
Wolfgang, DG2MDJ


Re: performance wsprdaemon on a RPI3

Bryan Klofas
 

Hey Rob--

Thanks for the tips on decreasing the "-o" flag if I run out of cycles. My current KF6ZEO spotting station is actually running on a Ubuntu 20.04 VM with 2 threads of a i3-5010U, so it's got enough horsepower. I'm building up a Pi for a remote site.

It might be helpful to add a bit more error logging if kiwirecorder can't access the SDR.

For instance, I just stopped wsprdaemon, git pull, started, and viewed the error logs. Nothing showed up using "-l e", but no spots were being uploaded.

It turns out that as soon as I stopped wsprdaemon, the KiwiSDR started to update itself, with no incoming connections allowed. Judging by htop, it appears that kiwirecorder is crashlooping. Running kiwirecorder by hand results in:

kiwi.client.KiwiDownError: 192.168.1.82: server is down atm

However, the recovery worked well. As soon as the server came back up, kiwirecorder stopped crashing and wsprdaemon started uploading spots. So maybe I'm getting a bit too into the weeds here.

Thanks for continuing to work on wsprdaemon, have a great weekend!
--
Bryan Klofas KF6ZEO

On 5/26/22 18:32, Rob Robinett wrote:
Hi Bryan,
I see from http://wspr.rocks/livequeries/ <http://wspr.rocks/livequeries/> that you are still running 3.0.2.3. You would benefit from updating your WD by running:
git pull
wd -z
wd -a
I have just installed Wd 3.0.2 at many of the top sites and have found how to use some of its features to ensure there is no CPU overloading on the WD server.  Logging is much improved in WD 3.0, so wsprd timeouts and other errors which were silently handled (tom some extent) by WD 2.10 are now much more visible.  To see log lines with ERROR execute:
wd -l e    (show Log errors)
You can ignore the "ERROR: only x o y spots accepted by wsprnet.org" lines, but any other error lines should be investigated.
If you see "ERROR: timeout..." lines, then you are running out of CPU cycles and you should try adding this line to your conf file:
WSPRD_CMD_FLAGS="-C 500 -o 3 -d"
At one especially challenged site I had to go down from the default '-o 4' to:
WSPRD_CMD_FLAGS="-C 500 -o 2 -d"
Even '-o 2' didn't seem to affect the number of decoded spots, so users with Pi 3bs may be able to scan 14+ bands.


Re: Memory leak (Bullseye)

Rob Robinett
 

The memory leak is in the Bash version 5.1.4 included in bullseye.  Gwyn has compiled Bash 5.1.16 on his bullseye Pi 3b and that fixes the problem.  I have no insight into if/when they will update the Bash is bullseye.

I switched my Pi4 to the 64 bit Ubuntu for the Pi which includes Bash 5.1.16 and it runs with no leak.  That version of Ubuntu is offered as an option in the 'Raspberry Pi Imager' which I run on my Mac to load microSD cards.  Burning the card and then setting it up in the Pi took me about 15 minutes, but I do have a lot of experience with that process.

Rob

On Fri, May 27, 2022 at 7:01 AM John <johnk5mo@...> wrote:
Rob mentions:

in your case the much bigger problem is a memory leak in the Bash 5.1.4 included in bullseye.  Gwyn G3ZIL identified that problem which leads the Pi to run out of memory in 1-5 days.

I now see this too, in my Pi4 install of 3.0.2 .  It's running great otherwise.  ("other than that, how did you like the play Mrs Lincoln?").   Do I understand this is an issue with Bash?

While I can restart my system every 5 days or so, does anyone know if this is likely to be fixed in a new release of Bash, or is it associated only with the combination of Bash and WD?

Thanks. It's probably a dumb question, but I'd rather wait and update Bash than build a new system.

John K5MO



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


Memory leak (Bullseye)

John K5MO
 

Rob mentions:

in your case the much bigger problem is a memory leak in the Bash 5.1.4 included in bullseye.  Gwyn G3ZIL identified that problem which leads the Pi to run out of memory in 1-5 days.

I now see this too, in my Pi4 install of 3.0.2 .  It's running great otherwise.  ("other than that, how did you like the play Mrs Lincoln?").   Do I understand this is an issue with Bash?

While I can restart my system every 5 days or so, does anyone know if this is likely to be fixed in a new release of Bash, or is it associated only with the combination of Bash and WD?

Thanks. It's probably a dumb question, but I'd rather wait and update Bash than build a new system.

John K5MO


Re: wsprdaemon with SDRplay devices on Raspberry Pi 4

Bruce KX4AZ
 

On Thu, May 26, 2022 at 11:20 PM, Rob Robinett wrote:
... I have ordered one of those clones from ebay if only to compare it against my RP2.
...The big issue with using any of those SDRs for VHF/UHF WSPR is calibrating its frequency settings
Thanks Rob, looking forward to hearing how well it works.  I ordered one as well from Aliexpress - the one with five SMA filter inputs.  The main difference versus the single input with the DIP switches is bandwidth claimed (2 GHz versus 1 GHz for the 5 inputs).  Presumably all of those 5 SMA inputs add enough extra capacitance to roll things off at a lower frequency.  They claim there is a 0.5 ppm TXCO on board so perhaps after calibrating against a GPSDO the accuracy will be good enough for VHF/UHF WSPR.  Unless you can swamp out the TXCO by feeding it a stronger external clock, perhaps.  In any event, even given the outdated RSP1 design, it would be a significant upgrade from the RTL-SDR direct mode for HF, with those extra bits as well as the lack of aliasing for the >14.4 MHz region, not to mention the much wider bandwidth, and similar cost. 


Re: wsprdaemon with SDRplay devices on Raspberry Pi 4

Erwin - PE3ES - F4VTQ
 

First of all these are clones of the way outdated version RSP1, not the later RSP1a. And also the "designer" tells it is a simplified design.
So I would not be to hopeful on performance.
If it will work with the needed latest official SDRplay API versions needs to be seen as well.

Well, one can always hope.

Cheers


Re: wsprdaemon with SDRplay devices on Raspberry Pi 4

Rob Robinett
 

Perhaps  I could tune the RP1/2 to a carrier generated by a GPSDO on the bench next to the RP and then use the measured tuning error to adjust the WSPR tuning frequency.  That isn't nearly as good as driving the clock of the RP1/2, but no soldering required ;=)

On Thu, May 26, 2022 at 8:46 PM Glenn Elmore <n6gn@...> wrote:
Unfortunately upon surveying  > 30 OTA HDTV broadcasts here on Colorado
's Front Range with my GPSDO referenced 0-2 GHz Frequency Extender,
hearing HDTV ATSC pilot carriers from well South of Denver up to the
Wyoming border, I find almost *NONE* of them on the 'correct' ATSC spot.
They are generally within 1 kHz (FCC spec?) but they deliberately offset
in order to avoid QRMing each other. Unless you can get the
engineer-in-charge to tell you what their exact offset is (if they know
it) I don't think these signals are nearly as useful as first hoped.

So much for using ATSC for the truly accurate frequency information it
might otherwise provide. It's slated to disappear anyway...

On 5/26/22 21:20, Rob Robinett wrote:
> That RP clone doesn't appear to have an external clock input option,
> so I can use the "calibrate against a local ATSC pilot carrier' if
> those can be trusted.







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


Re: wsprdaemon with SDRplay devices on Raspberry Pi 4

Glenn Elmore
 

Unfortunately upon surveying  > 30 OTA HDTV broadcasts here on Colorado 's Front Range with my GPSDO referenced 0-2 GHz Frequency Extender, hearing HDTV ATSC pilot carriers from well South of Denver up to the Wyoming border, I find almost *NONE* of them on the 'correct' ATSC spot. They are generally within 1 kHz (FCC spec?) but they deliberately offset in order to avoid QRMing each other. Unless you can get the engineer-in-charge to tell you what their exact offset is (if they know it) I don't think these signals are nearly as useful as first hoped.

So much for using ATSC for the truly accurate frequency information it might otherwise provide. It's slated to disappear anyway...

On 5/26/22 21:20, Rob Robinett wrote:
That RP clone doesn't appear to have an external clock input option, so I can use the "calibrate against a local ATSC pilot carrier' if those can be trusted.


Re: wsprdaemon with SDRplay devices on Raspberry Pi 4

Rob Robinett
 

Hi Bruce,

Thanks for that post.  I have ordered one of those clones from ebay if only to compare it against my RP2.

I had my RP2 working with WD 3.0 last year, and I will check to see if that code is still working.  

The big issue with using any of those SDRs for VHF/UHF WSPR is calibrating its frequency settings.  I can drive the RP2 from my Bodnar to get 1 hz accuracy and stability,  but even an RTL-SDR is stable enough to decode WSPR on 23 cm if I can calibrate its tuning.   That RP clone doesn't appear to have an external clock input option, so I can use the "calibrate against a local ATSC pilot carrier' if those can be trusted.


I have


Re: performance wsprdaemon on a RPI3

Rob Robinett
 

Hi Bryan,

I see from http://wspr.rocks/livequeries/ that you are still running 3.0.2.3.  You would benefit from updating your WD by running:

git pull
wd -z
wd -a

I have just installed Wd 3.0.2 at many of the top sites and have found how to use some of its features to ensure there is no CPU overloading on the WD server.  Logging is much improved in WD 3.0, so wsprd timeouts and other errors which were silently handled (tom some extent) by WD 2.10 are now much more visible.  To see log lines with ERROR execute:

wd -l e    (show Log errors)

You can ignore the "ERROR: only x o y spots accepted by wsprnet.org" lines, but any other error lines should be investigated.

If you see "ERROR: timeout..." lines, then you are running out of CPU cycles and you should try adding this line to your conf file:

WSPRD_CMD_FLAGS="-C 500 -o 3 -d"

At one especially challenged site I had to go down from the default '-o 4' to:

WSPRD_CMD_FLAGS="-C 500 -o 2 -d"

Even '-o 2' didn't seem to affect the number of decoded spots, so users with Pi 3bs may be able to scan 14+ bands.


Re: Rejected

Jim Lill
 

to date, nearly every misformed spot has been missing a grid, so that would be an easy filter I think

On 5/26/22 15:00, Rob Robinett wrote:

If you send me a list of rejected spots I will try to enhance the filtering I already do on spots before uploading them
thanks

On Thu, May 26, 2022 at 11:55 AM Jim Lill <jim@...> wrote:


I have started tracking which spots get rejected on wsprnet uploads. The wsprdaemon.sh -le command in v3.02 is useful for doing this. I have found 2 categories so far

  • bad decodes or otherwise misformed spots
  • dupes that come from uploads on the 60/60eu and 80/80eu bands. For example G4ZFQ on 60/60eu on the same upload cyles will result in one being thrown out as a dupe


-Jim

WA2ZKD








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


Re: Rejected

Jim Lill
 

I informed him.... and he is going to revise his scheme at some point

On 5/26/22 15:08, Rob Robinett wrote:

I think G4ZFQ is the only site transmitting on both 60M bands during the same WSPR cycle.
Perhaps he too doesn't know that 1/2 of such spots are being rejected by wsprnet.org

On Thu, May 26, 2022 at 12:01 PM Rob Robinett via groups.io <rob=robinett.us@groups.io> wrote:
If you send me a list of rejected spots I will try to enhance the filtering I already do on spots before uploading them
thanks

On Thu, May 26, 2022 at 11:55 AM Jim Lill <jim@...> wrote:


I have started tracking which spots get rejected on wsprnet uploads. The wsprdaemon.sh -le command in v3.02 is useful for doing this. I have found 2 categories so far

  • bad decodes or otherwise misformed spots
  • dupes that come from uploads on the 60/60eu and 80/80eu bands. For example G4ZFQ on 60/60eu on the same upload cyles will result in one being thrown out as a dupe


-Jim

WA2ZKD








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


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


Re: wsprdaemon with SDRplay devices on Raspberry Pi 4

Bruce KX4AZ
 

I happened to notice on Aliexpress (search for 'RSP1') there are a ton of RSP1 clones based on the msi2500 chip, that have either a single input with DIP switches for input filtering, or are equipped with 5 separate filtered inputs for different ranges (snapshots attached)....though for HF there is only a single "0-30 MHz" filter.  The pricing (generally <$20) would make them very competitive with the humble RTL-SDR dongles, though I haven't seen any performance tests for this new RSP1 clone "flavor".

If the new wspardaemon version happens to work with this variety of an RSP1 clone and if the performance at least matches that of the RTL-SDR, this could be a very interesting option for WSPR spotting.

761 - 780 of 1656