Date   

wspr.live database queries

Stefan HB9TMC
 

Hi,

Does anybody know the status of db1.wspr.live and db2.wspr.live?
They don't seem to be responding to database queries since yesterday morning.

Thanks, 73
Stefan


Re: performance wsprdaemon on a RPI3

Bryan Klofas
 

Hey Rob--

I've been staring at "htop" for too long, trying to track down a problem where if wsprd runs for more than 1 minute, spots are not decoded or posted.

I'm running wsprdaemon on a Pi 2 from 40m-10m, which works fine for all bands except 20 meters during the daytime when this problem happens. I know I should upgrade my Pi2, but I can't seem to buy a Pi4....

Upping the verbosity levels of the logs, it appears that many things happen 1 minute after the end of the WSPR period:

Thu Mar 31 00:49:00 UTC 2022: watchdog_daemon() is awake
Thu Mar 31 00:49:00 UTC 2022: running update_master_hashtable()
Thu Mar 31 00:49:01 UTC 2022: update_master_hashtable found no rx/band directories
Thu Mar 31 00:49:01 UTC 2022: spawn_upload_daemons() start
Thu Mar 31 00:49:01 UTC 2022: spawn_upload_to_wsprnet_daemon() INFO: uploading job with pid 12499 is already running
Thu Mar 31 00:49:01 UTC 2022: spawn_ftp_upload_to_wsprdaemon_daemon() INFO: uploading job for '/home/pi/wsprdaemon-bklofas/uploads.d/wsprdaemon.d' with pid 12502 is already running

.......

Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() Found running_pid '12478' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() Found running_pid '12499' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() Found running_pid '12502' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() Found running_pid '12565' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() Found running_pid '12609' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() Found running_pid '12696' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() Found running_pid '12699' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() WARNING: did not find running_pid '3207' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
pi 3207 0.0 0.0 6728 456 pts/1 S 00:48 0:00 \_ timeout 110 nice /home/pi/wsprdaemon-bklofas/bin/wsprd -c -C 500 -o 4 -d -w -f 14.0956 220331_0046.wav
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() adding running zombie '3207' to kill list
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() WARNING: did not find running_pid '3208' in expected_pids ' 12478 12499 12502 12565 12609 12699 12696'
pi 3208 100 1.3 14944 13148 pts/1 RN 00:48 0:52 \_ /home/pi/wsprdaemon-bklofas/bin/wsprd -c -C 500 -o 4 -d -w -f 14.0956 220331_0046.wav
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() adding running zombie '3208' to kill list
Thu Mar 31 00:49:02 UTC 2022: check_for_zombies() killing pids ' 3207 3208'
PID TTY STAT TIME COMMAND
3207 pts/1 S 0:00 timeout 110 nice /home/pi/wsprdaemon-bklofas/bin/wsprd -c -C 500 -o 4 -d -w -f 14.0956 220331_0046.wav
3208 pts/1 RN 0:52 /home/pi/wsprdaemon-bklofas/bin/wsprd -c -C 500 -o 4 -d -w -f 14.0956 220331_0046.wav


So from what I can tell, the WSPR period is 00:46 to 00:48, then wsprd gets called at 00:48:06. So far so good. But then at 00:49:01, it tries to upload the decoded spots for this period. But wsprd hasn't finished, so there are no spots to upload.

Then at 00:49:02 zombies are checked for, and the running wsprd process is found and killed.

Is my analysis of the logs correct? So even though wsprd is called with "timeout 110" and nice, it actually needs to finish within 52 real seconds (because wsprd gets started 6 seconds after the WSPR period ends). Is it possible to push this 1 minute to 100 seconds or a bit longer?

I'm not sure which is the bigger issue: uploading spots before wsprd is finished, or killing wsprd. Allowing wsprd to go for 100 seconds wouldn't matter if the spot uploader checks at 52 seconds.

Thanks!
--
Bryan Klofas KF6ZEO

On 3/2/22 06:59, Rob Robinett wrote:
Hi Hans,
You are of course welcome to experiment with increasing the wsprd TIMEOUT value beyond the default beyond 110 seconds, but if it takes wsprd longer than 120 seconds  to execute, then the WD decoding thread will gradually fall behind the wav file recording and those wav files will fill up your 3000 MBtye //tmp/wsprdaemon file system to overflowing.  Your reports stimulated me to study the performance of the WD Pi at KPH where there are 14 bands of WD decoding running on a Pi 4. I found that in order for that Pi to finish its wsprd withing 120 seconds I had to modify the config file by adding the line:
WSPRD_CMD_FLAGS="-C 500 -o 3 -d"
You can't use the summary lines in 'top' without understanding that there are 4 cpu cores in the Pi's ARM CPU and the wsprd of each band runs on only one of those 4 cores.  So if your 40M wspd were the only code running for the whole of the 120 second wsprd cycle, 'top' would show the CPU as only 25% busy.  Type '1' while in 'top' and it will show you the state of each of the CPU cores.
But you are fortunately to have a good receive site with so many signals coming from your antenna that your QTH deserves a i5 rather than cripple 'wsprd' in order to get it to run on a Pi.
73,
Rob
On Wed, Mar 2, 2022 at 4:20 AM Hans V alphen via groups.io <http://groups.io> <pa0ehg@... <mailto:amsat.org@groups.io>> wrote:
Hi Rob,
I have been running WSPRdaemon on a RPI3 for a few days now and I
have many problems looking as overload of the RPI.
Looking at the processor from the RPI I see a CPU usage which never
exceeds 90%, I am only using the RPI for two frequencies WSPR on
80eu and 80 mtr.
It looks like the CPU usage is not the big problem I find. I have
the impression it has to do with a time out of 110 seconds. I have
been looking into wsprdaemon.sh and I do find timeout but to be
honest I do not quite understand what all is done in that part of
the wsprdaemon.sh.
What I see in practical performance is a sudden breakdown in
performance. I think It's at the point where the time out is
exceeded. As soon as this happens the WSPRDaemon is no longer
decoding spots. It looks like .wav files are missing and decoding is
not possible.
It seems to happen as soon as evening conditions start and it
continues until the end of evening conditions. During the night
there are sometimes period with no problems but as soon as I get 2
minute intervalls with close to 10 decodable spots (I know this from
my other setup) than it collapses.
I have two pictures where you can see what is happening.
The first picture shows the analysis  of the Kiwi with the RPI3, as
soon as evening conditions start the spots per over begin to hevave
strange. The second picture is the analysis of my second setup, it's
using the same antenna as the Kiwi and as you can see performance is
stable and much more spots decoded. Mind that the two pictures have
a different spots per over interval in the diagram.
Looking at the noise measurements I see a Kiwi which in my opinion
is working OK, I have carefully adjusted the input level so that
during the night it does not overload, which it did at my first few
days. Also the CPU usage of the KIwi is not very high and it does
not look like reason of the performance degradation.
Now my question: would it be worth to try and increase the time out
period of 110 seconds and how could this be done ??
Best solution probably is leaving the RPI3 for what it is and use a
better machine. This morning I received a refurbished I5 for that
but I have to see and find to get Ubuntu on it and get things going.
So perhaps your advice could also be to leave the RPI3 and not
experiment with the time out. On the other hand as the CPU usage of
the RPI3 does not look to be the big problem it would be interesting
to try and understand the problem,.
73's  Hans DL/PA0EHG
--
Rob Robinett
AI6VN
rob@... <mailto:rob@...>
mobile: +1 650 218 8896


Re: What are the sh.thd.xxxxx files?

Rob Robinett
 

Another forum contributor mentioned this phenomenon and pointed me at https://github.com/scop/bash-completion/issues/199
WD 3.0 uses the 'here' redirection ('<<< "TEXT") and that article has prompted me to put on my TODO list removing such usage.
But I don't think these ss.thd.xxx files are a major short term problem

On Wed, Mar 30, 2022 at 12:07 PM Rolf Ekstrand <rekstrand@...> wrote:
Greetings y'all,

I have not been diving into the WD deep enough and being short of time to educate myself  in regards to the program.  I have a question.

Suddenly the tmp/ is filling up with sh.thd.xxxxx files.  What are they and is there anything I should do about it??

Rolf

K9DZT



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


What are the sh.thd.xxxxx files?

Rolf Ekstrand
 

Greetings y'all,

I have not been diving into the WD deep enough and being short of time to educate myself  in regards to the program.  I have a question.

Suddenly the tmp/ is filling up with sh.thd.xxxxx files.  What are they and is there anything I should do about it??

Rolf

K9DZT


Re: wsprdaemon with SDRplay devices on Raspberry Pi 4

Rob Robinett
 

There is already alpha level SDRPlay support in the WD 3.0 client.
I have just finished deploying the WD 3.0 servers needed to support the WD 3.0 clients and have the clients running at several sites.
Once I have debugged all the legacy features in 3.0 I'll work on the SDRPlay and other devices.


Re: wsprdaemon with SDRplay devices on Raspberry Pi 4

John Loftus
 

Hi Bruce,
Thank you for getting me up to date.
Yes - will be a fantastic way to go forward.
Regards,
John VK4CT / VK4EMM


Re: wsprdaemon with SDRplay devices on Raspberry Pi 4

Bruce KX4AZ
 

Rob posted this last month....will be fantastic if the other SDRs can be incorporated like that...

"For those of you who don't join our Wednesday 18:00 UTC Zoom call, I thought it would be useful to let you know that I am actively working on a major new version of WD which will include these major new features:

1) Support for the new FST4W transmission modes added in WSJT-x V2.3.0, in particular the 5,15, and 30 minute packets.  Each band configured to receive them  will consume up to 100+ MBytes of space in /tmp/wsprdaemon 
2) Support for additional SDRs supported by the SoapyAPI service.  These include SDRPlay, RTL-SDR, Red Pitaya and many others.

It may be several weeks before I have a v3.0 release candidate running at the beta sites, but I wanted WD users that it is still under active development."


wsprdaemon with SDRplay devices on Raspberry Pi 4

John Loftus
 

Hi Rob,

I'm wondering if you are working towards running wsprdaemon 
with SDR Play devices on a headless Raspberry Pi 4 

Regards,
John VK4CT


Re: Odroid XU4

Rob Robinett
 

I have finished my work on the WD 3.0 servers and am turning my attention to WD 3.0 clients. 
As a first step I added a command to show new error lines in the 200+ log files in the 27 channel KFS system, and was surprised to find frequent wdprd decode job timeout errors when the Thinkcenter couldn't finish decoding in 110 seconds.
So Pi4 and Odroid systems may be useful only for sites with less than 20 receive channels
 


Re: Getting a second KiwiSDR

Jim Lill
 

Thanks, I have looked at that. Just waiting for snow to melt (now gone) and spring to inspect a few things on the antennas

On 3/24/22 16:32, Rob Robinett wrote:

Glen N6gn has written an application note on improving receive system noise performance which you might find useful:


On Thu, Mar 24, 2022 at 12:45 PM Jim Lill <jim@...> wrote:

Neither of my 2 systems are great, but still far better than too many out there.  Mine is a constant battle against living in an RF swamp such as I do.

73

-Jim

On 3/24/22 14:33, Bruce KX4AZ wrote:
On Thu, Mar 24, 2022 at 01:33 PM, Jim Lill wrote:

you may find that your EFHW is prone to noise pick also

Jim,
Yes, that is absolutely the case, given the coax shield serving as the counterpoise.  That said, I have two common mode chokes in place, one where the coax meets the house (50 feet downstream from the EFHW transformer), and a second one where the coax meets the receiver, which makes it tolerable for my purposes.  Having that full 0-30 MHz spectrum view from the KiwiSDR at this EM83 grid is going to make further antenna/feedline comparisons (such as a non-resonant dipole, active whip, MLA-30 loop, etc etc) so much easier to carry out, and give me the motivation to make it public, and/or get wsprdaemon decoding on a PI4.

It just astounds me how many public Kiwis have noise-ridden, ugly waterfalls that render them barely usable.  When the antenna at my "KX4AZ/T" site in MI got clobbered in December  I added a "broken antenna" disclaimer, to acknowledge the poor, but still partially usable status.  Had it looked as bad as some of the other pubic KiwisI wouldn't have left it running.  OK, end of rant.  Life is good.  And long live the KiwiSDR!
Bruce


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


Re: Getting a second KiwiSDR

Rob Robinett
 

Glen N6gn has written an application note on improving receive system noise performance which you might find useful:


On Thu, Mar 24, 2022 at 12:45 PM Jim Lill <jim@...> wrote:

Neither of my 2 systems are great, but still far better than too many out there.  Mine is a constant battle against living in an RF swamp such as I do.

73

-Jim

On 3/24/22 14:33, Bruce KX4AZ wrote:
On Thu, Mar 24, 2022 at 01:33 PM, Jim Lill wrote:

you may find that your EFHW is prone to noise pick also

Jim,
Yes, that is absolutely the case, given the coax shield serving as the counterpoise.  That said, I have two common mode chokes in place, one where the coax meets the house (50 feet downstream from the EFHW transformer), and a second one where the coax meets the receiver, which makes it tolerable for my purposes.  Having that full 0-30 MHz spectrum view from the KiwiSDR at this EM83 grid is going to make further antenna/feedline comparisons (such as a non-resonant dipole, active whip, MLA-30 loop, etc etc) so much easier to carry out, and give me the motivation to make it public, and/or get wsprdaemon decoding on a PI4.

It just astounds me how many public Kiwis have noise-ridden, ugly waterfalls that render them barely usable.  When the antenna at my "KX4AZ/T" site in MI got clobbered in December  I added a "broken antenna" disclaimer, to acknowledge the poor, but still partially usable status.  Had it looked as bad as some of the other pubic KiwisI wouldn't have left it running.  OK, end of rant.  Life is good.  And long live the KiwiSDR!
Bruce



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


Re: Getting a second KiwiSDR

Jim Lill
 

Neither of my 2 systems are great, but still far better than too many out there.  Mine is a constant battle against living in an RF swamp such as I do.

73

-Jim

On 3/24/22 14:33, Bruce KX4AZ wrote:

On Thu, Mar 24, 2022 at 01:33 PM, Jim Lill wrote:

you may find that your EFHW is prone to noise pick also

Jim,
Yes, that is absolutely the case, given the coax shield serving as the counterpoise.  That said, I have two common mode chokes in place, one where the coax meets the house (50 feet downstream from the EFHW transformer), and a second one where the coax meets the receiver, which makes it tolerable for my purposes.  Having that full 0-30 MHz spectrum view from the KiwiSDR at this EM83 grid is going to make further antenna/feedline comparisons (such as a non-resonant dipole, active whip, MLA-30 loop, etc etc) so much easier to carry out, and give me the motivation to make it public, and/or get wsprdaemon decoding on a PI4.

It just astounds me how many public Kiwis have noise-ridden, ugly waterfalls that render them barely usable.  When the antenna at my "KX4AZ/T" site in MI got clobbered in December  I added a "broken antenna" disclaimer, to acknowledge the poor, but still partially usable status.  Had it looked as bad as some of the other pubic KiwisI wouldn't have left it running.  OK, end of rant.  Life is good.  And long live the KiwiSDR!
Bruce


Re: Getting a second KiwiSDR

Bruce KX4AZ
 

On Thu, Mar 24, 2022 at 01:33 PM, Jim Lill wrote:

you may find that your EFHW is prone to noise pick also

Jim,
Yes, that is absolutely the case, given the coax shield serving as the counterpoise.  That said, I have two common mode chokes in place, one where the coax meets the house (50 feet downstream from the EFHW transformer), and a second one where the coax meets the receiver, which makes it tolerable for my purposes.  Having that full 0-30 MHz spectrum view from the KiwiSDR at this EM83 grid is going to make further antenna/feedline comparisons (such as a non-resonant dipole, active whip, MLA-30 loop, etc etc) so much easier to carry out, and give me the motivation to make it public, and/or get wsprdaemon decoding on a PI4.

It just astounds me how many public Kiwis have noise-ridden, ugly waterfalls that render them barely usable.  When the antenna at my "KX4AZ/T" site in MI got clobbered in December  I added a "broken antenna" disclaimer, to acknowledge the poor, but still partially usable status.  Had it looked as bad as some of the other pubic KiwisI wouldn't have left it running.  OK, end of rant.  Life is good.  And long live the KiwiSDR!
Bruce


Re: Getting a second KiwiSDR

Jim Lill
 

you may find that your EFHW is prone to noise pick also

On 3/23/22 18:02, Bruce KX4AZ wrote:

Very surprised that my order arrived from the UK exactly seven days after I placed the order.  Full kit including the BB so it was a great deal.  Began setting it up yesterday with my EFHW antenna.  While doing that I checked out some of the publicly accessible Kiwis in SE region of the US....so many noise-ridden waterfalls out there.


Re: Odroid XU4

Rolf Ekstrand
 

Jim,

Sounds like a deal to me as any X86 unit would be a bit more expensive.   I think I'll try the XU4  

-Rolf

K9DZT

  

 


Re: Getting a second KiwiSDR

Bruce KX4AZ
 

Very surprised that my order arrived from the UK exactly seven days after I placed the order.  Full kit including the BB so it was a great deal.  Began setting it up yesterday with my EFHW antenna.  While doing that I checked out some of the publicly accessible Kiwis in SE region of the US....so many noise-ridden waterfalls out there.


Re: Getting a second KiwiSDR

Jim Lill
 

I bought 2 from them, total cost with freight to US was US$500

They arrive din less than 2 weeks


-Jim

On 3/15/22 14:43, KD2OM wrote:

https://www.hamradio.co.uk/sdr-seeed-studio/seeedstudio/kiwisdr-10-khz-to-30-mhz-web-interface-pd-13595.php


On 3/15/22 17:40, Jim Lill wrote:

were you going to share the link Steve

On 3/15/22 10:34, KD2OM wrote:
I  found them. A reasonable price. They say they have cases in stock as well. Looks like a full kit, congrats.


On Mar 15, 2022, at 10:17, KD2OM <steve@...> wrote:

 Mouser has 306 BBAI in stock and 251 BB Black.




On Mar 15, 2022, at 10:04, Rob Robinett <rob@...> wrote:


I would call the vendor and check what you are getting.
It is my understanding that the BB are impossible to get, so if it is just the radio you may not be able to build a complete Kiwi radio for some time

On Tue, Mar 15, 2022 at 6:58 AM KD2OM <steve@...> wrote:

That sure sounds like the price of just the radio. Keep us posted.

73

Steve KD2OM

On 3/15/22 13:29, Bruce KX4AZ wrote:
I decided to pull the trigger on getting a second KiwiSDR after coming across an excellent deal from a well known UK amateur radio vendor.  The total kit price came to around $240 USD including shipping.  Hard to beat a price like that....unless I got tricked and find out it comes without a BB board (fingers crossed!).  And hopefully the shipping process won't be as slow as for things I order from Aliexpress.


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


Re: Odroid XU4

Jim Lill
 

I run the XU4 headless, no monitor or keyboard. I just ssh into it and do everything that way.  I run 26 channels on it without as issue. 630-10M on from one kiwi and 2200-12M from a 2nd kiwi. The kiwi's each have a different type of antenna system.


-Jim

WA2ZKD


On 3/23/22 14:20, Rolf Ekstrand wrote:

Jim,

I would like to try it as Odroid seems to have them in stock now.   This as even raspberries are getting in short supply these days  and I don't like the HDMI connections as they loose connections over time if you move the unit around.  This more so on the 400 even if you use the short flexible  HDMI to micro transition cable.  

I think you said way back that you are using 14 channels on your XU4  and that would be plenty for me.   Still battling heavy interference here between 2.0 - 3.0 Mhz  and  I changed to RTL-SDR 2,6 Mhz High pass but that is not enough to knock down the racket.  I am thinking of using high performance 5 Mhz or there about to knock it out of the Kiwi and then  use single band very narrow band band pass ahead of a high dynamic range RX's  for 3.5  and below. This together with single band magnetic loop for each band and rx. 

Thus I'll run the Kiwi on 7 -  28 Mhz  ( 7 channels as I am running right now) and hopefully 3.5 and 1.8 on single band separate rx's.   I am using the Kiwi with a BB Black here so I am limited to  8 Channels on the Kiwi anyway.     

-Rolf

K9DZT


Re: Odroid XU4

Rolf Ekstrand
 

Jim,

I would like to try it as Odroid seems to have them in stock now.   This as even raspberries are getting in short supply these days  and I don't like the HDMI connections as they loose connections over time if you move the unit around.  This more so on the 400 even if you use the short flexible  HDMI to micro transition cable.  

I think you said way back that you are using 14 channels on your XU4  and that would be plenty for me.   Still battling heavy interference here between 2.0 - 3.0 Mhz  and  I changed to RTL-SDR 2,6 Mhz High pass but that is not enough to knock down the racket.  I am thinking of using high performance 5 Mhz or there about to knock it out of the Kiwi and then  use single band very narrow band band pass ahead of a high dynamic range RX's  for 3.5  and below. This together with single band magnetic loop for each band and rx. 

Thus I'll run the Kiwi on 7 -  28 Mhz  ( 7 channels as I am running right now) and hopefully 3.5 and 1.8 on single band separate rx's.   I am using the Kiwi with a BB Black here so I am limited to  8 Channels on the Kiwi anyway.     

-Rolf

K9DZT


Re: Getting a second KiwiSDR

KD2OM
 

were you going to share the link Steve

On 3/15/22 10:34, KD2OM wrote:
I  found them. A reasonable price. They say they have cases in stock as well. Looks like a full kit, congrats.


On Mar 15, 2022, at 10:17, KD2OM <steve@...> wrote:

 Mouser has 306 BBAI in stock and 251 BB Black.




On Mar 15, 2022, at 10:04, Rob Robinett <rob@...> wrote:


I would call the vendor and check what you are getting.
It is my understanding that the BB are impossible to get, so if it is just the radio you may not be able to build a complete Kiwi radio for some time

On Tue, Mar 15, 2022 at 6:58 AM KD2OM <steve@...> wrote:

That sure sounds like the price of just the radio. Keep us posted.

73

Steve KD2OM

On 3/15/22 13:29, Bruce KX4AZ wrote:
I decided to pull the trigger on getting a second KiwiSDR after coming across an excellent deal from a well known UK amateur radio vendor.  The total kit price came to around $240 USD including shipping.  Hard to beat a price like that....unless I got tricked and find out it comes without a BB board (fingers crossed!).  And hopefully the shipping process won't be as slow as for things I order from Aliexpress.


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

901 - 920 of 1670