Date   

Re: WD 3.0 beta testing

Rob Robinett
 

I have checked in a fix for the problem where MERGE would not select the best SNR.
'git pull'  to get that fix.
'wd -V' will print "Version = 3.0.1" if you are running that fixed code.


WD 3.0 beta testing

Rob Robinett
 

The WD 3.0 software has been running at my AI6VN/KH6, KPH and KFS sites for several months, and in the last two weeks I have helped bring it up on an additional 8 sites.  In most of those installations it seems to run as stably as 2.10k and 3.0 includes many 'behind-the-scenes' enhancements to slightly improve the number of spots reported.  I have also just created a Telegram 'Wsprdaemon' channel which I will monitor.  WD 3.0 includes a remote support option which when enabled in your conf file will, with your permission, allow me to log on to your WD server to help with installation and debugging.

So I am inviting those who are interested in joining the 3.0 beta program to install it.

For existing WD 2.10 users:  

cd ~/wsprdaemon
./wsprdaemon.sh -z            
git pull
git checkout v3.0
./wsprdaemon.sh -a

The ./wsprdaemon.conf file formats are backwards compatible, and you can return to use 2.10 by executing 'git checkout main' in the above commands.


Re: wspr outage?

Rob Robinett
 

Thanks to Gywn I found a problem was due to a corrupt change which had crept into the code on WD1 and WD3.
I have fixed that problem on both WD1 and WD3 and they are once again running.
The gaps in the spot tables caused by my bug were refilled, so WD1 and WD3 should be completely up to date.
Sorry for the disruptions.


On Tue, Apr 26, 2022 at 3:52 AM Bruce KX4AZ <bruce@...> wrote:
It looks like the last spots accessible at wspr.rocks are from 0116 UTC today (26 April 2022).  Or is that an error on my end?



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


wspr outage?

Bruce KX4AZ
 

It looks like the last spots accessible at wspr.rocks are from 0116 UTC today (26 April 2022).  Or is that an error on my end?


Re: 3 letter call sign for special event

jks
 


Re: 3 letter call sign for special event

Bruce KX4AZ
 

Thanks Rob, that's what I had begun to surmise, just wanted to re-confirm before I push any further with the WSJT-x groups.io.  I posted the problem there the other day before I fully understood the nuances of what was happening and how the Type 1/2/3 messages are encoded/decoded. Armed with this knowledge and your confirmation that wsprd is what needs "fixing", I'll start a new thread there.
73,
Bruce KX4AZ


Re: 3 letter call sign for special event

Rob Robinett
 

WD executes the binary 'wsprd' taken from the WSJT-x distribution.  So if WSJT-x reports 'N1D' Wd should also report it.
So I would encourage you to post your problem to the WSJT-x developers forum and report back to us when it is fixed there.

On Sat, Apr 23, 2022 at 8:34 AM Bruce KX4AZ <bruce@...> wrote:
Just a follow up, running the 'N1D/4' special event WSPR beacon with the (compound) call sign is working well for spots from the array of decoders out there.  I am curious whether the future 3.0 wsprdaemon version will have the ability to decode/upload 1x1 call signs (i.e. Type 1 messages) like N1D.  Or does that ability await a "fix" from the folks who work on WSJT-x?



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


Re: 3 letter call sign for special event

Bruce KX4AZ
 

Just a follow up, running the 'N1D/4' special event WSPR beacon with the (compound) call sign is working well for spots from the array of decoders out there.  I am curious whether the future 3.0 wsprdaemon version will have the ability to decode/upload 1x1 call signs (i.e. Type 1 messages) like N1D.  Or does that ability await a "fix" from the folks who work on WSJT-x?


Re: max wsprd decoding time is only 60sec ?

Rob Robinett
 

Hi Bryan,

Your report adds to my sense that WD 3.0 is ready for wider beta testing.  So I have amended the README to encourage more users to try it out.

Rob

On Thu, Apr 21, 2022 at 9:34 PM Bryan Klofas <bklofas@...> wrote:
Hey Rob--

Thanks for the confirmation about the 60 seconds.

I did just switch over to WD_3.0a, it seems to be working fine for me.
Lots of spots are being uploaded, and it seems like reducing the 6200
line bash script will make it easier on everyone! Running it on a
i3-5010U is plenty fast enough, I'll try my older Pis soon.

I was initially dissuaded for trying v3.0 because the README says "The
client mode is running at AI6VN/KH6 but it isn't really ready for even
alpha testing at other sites." I guess that's not true anymore.

Thanks for keeping wsprdaemon updated, you're doing a great job!
--
Bryan Klofas KF6ZEO

On 4/21/22 09:08, Rob Robinett wrote:
> Hi Ulli and Bryan,
>
> I'm sorry that I didn't respond to Bryan's earlier email about the
> problem he identified in V2.10.  He seems to have correctly identified
> the zombie check function which runs every odd minute as the source of
> the 'terminates after 60 seconds' problem.
>
> Like much of the WD code, the zombie checking has been extensively
> revised in WD 3.0.  So for those running WD 2.10 who experience this
> problem, I would suggest trying WD 3.0
>
> Rob
>
> On Thu, Apr 21, 2022 at 8:58 AM Bryan Klofas <bklofas@...
> <mailto:bklofas@...>> wrote:
>
>     Hey Ulli--
>
>     I have noticed this problem also, and posted about it back at the
>     end of
>     March. You can increase the verbosity of the wsprdaemon logs with
>     ./wsprdaemon -d and -D, and tail the wsprdaemon.log file, but it
>     seems a
>     bit buggy. I never got the "v=2" option to work, shown on line 111.
>
>     My earlier email:
>
>     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
>
>     On 4/21/22 01:18, ON5KQ wrote:
>      > Hi Rob,
>      > good morning from Belgium!
>      > I just upgraded from Vers 2.10l to version 3.0a
>      >
>      > A new wsprd version was uploaded and installed on the Rpi
>      > This new wsprd version is now running the wsprd process normally and
>      > doesn't stop after 60sec....
>      > So = Problem solved!
>      >
>      > I am now running Vers 3.0a
>      >
>      > Reading the help file of the new version with:
>      > ,/wsprdaemon.sh -h
>      >
>      > ... and learning of the new reporting functions....
>      > ./wsprdaemon.sh -l n   (for example)
>      >
>      > It is great!
>      > Thank you !
>      >
>
>
>
>
>
>
>
> --
> Rob Robinett
> AI6VN
> rob@... <mailto:rob@...>
> mobile: +1 650 218 8896
>







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


Re: max wsprd decoding time is only 60sec ?

Bryan Klofas
 

Hey Rob--

Thanks for the confirmation about the 60 seconds.

I did just switch over to WD_3.0a, it seems to be working fine for me. Lots of spots are being uploaded, and it seems like reducing the 6200 line bash script will make it easier on everyone! Running it on a i3-5010U is plenty fast enough, I'll try my older Pis soon.

I was initially dissuaded for trying v3.0 because the README says "The client mode is running at AI6VN/KH6 but it isn't really ready for even alpha testing at other sites." I guess that's not true anymore.

Thanks for keeping wsprdaemon updated, you're doing a great job!
--
Bryan Klofas KF6ZEO

On 4/21/22 09:08, Rob Robinett wrote:
Hi Ulli and Bryan,
I'm sorry that I didn't respond to Bryan's earlier email about the problem he identified in V2.10.  He seems to have correctly identified the zombie check function which runs every odd minute as the source of the 'terminates after 60 seconds' problem.
Like much of the WD code, the zombie checking has been extensively revised in WD 3.0.  So for those running WD 2.10 who experience this problem, I would suggest trying WD 3.0
Rob
On Thu, Apr 21, 2022 at 8:58 AM Bryan Klofas <bklofas@... <mailto:bklofas@...>> wrote:
Hey Ulli--
I have noticed this problem also, and posted about it back at the
end of
March. You can increase the verbosity of the wsprdaemon logs with
./wsprdaemon -d and -D, and tail the wsprdaemon.log file, but it
seems a
bit buggy. I never got the "v=2" option to work, shown on line 111.
My earlier email:
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
On 4/21/22 01:18, ON5KQ wrote:
> Hi Rob,
> good morning from Belgium!
> I just upgraded from Vers 2.10l to version 3.0a
>
> A new wsprd version was uploaded and installed on the Rpi
> This new wsprd version is now running the wsprd process normally and
> doesn't stop after 60sec....
> So = Problem solved!
>
> I am now running Vers 3.0a
>
> Reading the help file of the new version with:
> ,/wsprdaemon.sh -h
>
> ... and learning of the new reporting functions....
> ./wsprdaemon.sh -l n   (for example)
>
> It is great!
> Thank you !
>
--
Rob Robinett
AI6VN
rob@... <mailto:rob@...>
mobile: +1 650 218 8896


Re: Noise "Problem" at KPH/KFS

Glenn Elmore
 

Maybe only peripherally related to this discussion but here's a link to multiple ionosondes, managed by Terry Bullet, W0ASP , for Boulder Ionosonde (listed) and NOAA.

https://www.ngdc.noaa.gov/stp/IONO/rt-iono/latest/latest.html

I believe that one is 4kW ERP pointed straight up perhaps repeated CW-like sweeps every 15 minutes, but there are many and some not listed. I get the impression that these are ill-coordinated by the FCC or anyone else, some may be academic institutions.

 

Glenn

On 2022-04-21 11:13, Phil Karn wrote:

These chirped signals are always radars of some form, most likely CODAR or similar for sea state surveillance.

Anybody know what ionosphere sounders look like? I often see chirp radar bursts all over HF, usually around the MUF, but I don't know if they're military over-the-horizon radars or civilian ionosondes.

Chirped FM is a traditional radar signal but there are many others. Most would look like high speed data or even broadband noise, most likely with a repeating structure. Any repetitive signal, no matter how complex, will consist of spectral lines spaced by the repetition interval. E.g., when HAARP was active on 6.8 and 6.9 a week ago, one of their signals consisted of spectral lines about 49 Hz apart occupying a total of maybe 50 kHz. The lines were so sharp that you could still see other signals between them despite their enormous ERP.

Phil









Re: Noise "Problem" at KPH/KFS

Phil Karn
 

These chirped signals are always radars of some form, most likely CODAR or similar for sea state surveillance.

Anybody know what ionosphere sounders look like? I often see chirp radar bursts all over HF, usually around the MUF, but I don't know if they're military over-the-horizon radars or civilian ionosondes.

Chirped FM is a traditional radar signal but there are many others. Most would look like high speed data or even broadband noise, most likely with a repeating structure. Any repetitive signal, no matter how complex, will consist of spectral lines spaced by the repetition interval. E.g., when HAARP was active on 6.8 and 6.9 a week ago, one of their signals consisted of spectral lines about 49 Hz apart occupying a total of maybe 50 kHz. The lines were so sharp that you could still see other signals between them despite their enormous ERP.

Phil


Re: max wsprd decoding time is only 60sec ?

Phil Karn
 

My Fano decoder takes > 60 sec to run?! How big is the decoder move limit? A property of many variable-effort FEC decoders, including Fano, is that letting them work harder increases the chance of decoding garbage as something real. How often does this happen with WSPR?

Phil


Re: max wsprd decoding time is only 60sec ?

Rob Robinett
 

Hi Ulli and Bryan,

I'm sorry that I didn't respond to Bryan's earlier email about the problem he identified in V2.10.  He seems to have correctly identified the zombie check function which runs every odd minute as the source of the 'terminates after 60 seconds' problem.

Like much of the WD code, the zombie checking has been extensively revised in WD 3.0.  So for those running WD 2.10 who experience this problem, I would suggest trying WD 3.0

Rob

On Thu, Apr 21, 2022 at 8:58 AM Bryan Klofas <bklofas@...> wrote:
Hey Ulli--

I have noticed this problem also, and posted about it back at the end of
March. You can increase the verbosity of the wsprdaemon logs with
./wsprdaemon -d and -D, and tail the wsprdaemon.log file, but it seems a
bit buggy. I never got the "v=2" option to work, shown on line 111.

My earlier email:

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

On 4/21/22 01:18, ON5KQ wrote:
> Hi Rob,
> good morning from Belgium!
> I just upgraded from Vers 2.10l to version 3.0a
>
> A new wsprd version was uploaded and installed on the Rpi
> This new wsprd version is now running the wsprd process normally and
> doesn't stop after 60sec....
> So = Problem solved!
>
> I am now running Vers 3.0a
>
> Reading the help file of the new version with:
> ,/wsprdaemon.sh -h
>
> ... and learning of the new reporting functions....
> ./wsprdaemon.sh -l n   (for example)
>
> It is great!
> Thank you !
>







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


Re: max wsprd decoding time is only 60sec ?

Bryan Klofas
 

Hey Ulli--

I have noticed this problem also, and posted about it back at the end of March. You can increase the verbosity of the wsprdaemon logs with ./wsprdaemon -d and -D, and tail the wsprdaemon.log file, but it seems a bit buggy. I never got the "v=2" option to work, shown on line 111.

My earlier email:

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

On 4/21/22 01:18, ON5KQ wrote:
Hi Rob,
good morning from Belgium!
I just upgraded from Vers 2.10l to version 3.0a
A new wsprd version was uploaded and installed on the Rpi
This new wsprd version is now running the wsprd process normally and doesn't stop after 60sec....
So = Problem solved!
I am now running Vers 3.0a
Reading the help file of the new version with:
,/wsprdaemon.sh -h
... and learning of the new reporting functions....
./wsprdaemon.sh -l n   (for example)
It is great!
Thank you !


Re: Noise "Problem" at KPH/KFS

Jim Lill
 

more wave radar stuff....  CODAR like?

On 4/21/22 10:51, ON5KQ wrote:

I could not see the problem at kph today, but instead there was a similar signal about 20db weaker that yesterday observed at kfs at local morning time:



Obviously a 'real' signal, perhaps related to military. locally at the pacific coast in front of kfs ?!?
Yesterday the signal was much stronger and lower in frequency, reaching  -30dbm at kph...

Ulli, ON5KQ


Noise "Problem" at KPH/KFS

ON5KQ
 

I could not see the problem at kph today, but instead there was a similar signal about 20db weaker that yesterday observed at kfs at local morning time:



Obviously a 'real' signal, perhaps related to military. locally at the pacific coast in front of kfs ?!?
Yesterday the signal was much stronger and lower in frequency, reaching  -30dbm at kph...

Ulli, ON5KQ


Wspr.live noise data for wsprdaemon v3.0 - and other problem...

ON5KQ
 

Question:
is it "normal", that currently there is no noise data shown at wspr.live for spotters running wsprdaemon v3.0 ?

I cannot see any errors here at the client side running the new V 3.0a and noise data file is uploaded correctly, by my noise data is not shown at wspr.live

Another issue is, that even previously with vers 2.10 running, wsprdaemon noise data comparison did not work, when I try to compare ON5KQ Kiwi_1 with ON5KQ Kiwi 2 running a different antenna.
The goal in that case was to compare the reception performance of two different antennas with same spotter callsign using a merged setup
In that case I would expect the SNR difference close to zero DB and no curve at the bottom infinity....

What is wrong here ?

Ulli, ON5KQ


Re: 3 letter call sign for special event

Jim Lill
 

ignore my last.... too early here and didn't read all the received messages thoroughly!

On 4/20/22 20:47, Bruce KX4AZ wrote:

This afternoon I switched to using 'N1D/4' for the call sign, which is working OK., the '4' symbolizing the US call region 4.   Wasn't my first choice since it requires 2 cycles for a complete "spot", but it does the job, enabling spots by the full array of decoders out there.  And indeed I have verified the same decode problem with the 1x1 N1D call sign happens in the WSJT-x software, even though transmitting with just 'N1D' seems to be permitted, given that the Kiwi 1.3 decoder spots it.  So this is not a wsprdaemon issue per se, just the core decoder. 


Re: 3 letter call sign for special event

Jim Lill
 

Can you receive yourself on a 2nd radio with wsjt-x and see if it decodes your ZackTech correctly?

On 4/20/22 20:47, Bruce KX4AZ wrote:

This afternoon I switched to using 'N1D/4' for the call sign, which is working OK., the '4' symbolizing the US call region 4.   Wasn't my first choice since it requires 2 cycles for a complete "spot", but it does the job, enabling spots by the full array of decoders out there.  And indeed I have verified the same decode problem with the 1x1 N1D call sign happens in the WSJT-x software, even though transmitting with just 'N1D' seems to be permitted, given that the Kiwi 1.3 decoder spots it.  So this is not a wsprdaemon issue per se, just the core decoder. 

861 - 880 of 1670