|
With the latest system updates of the pi and latest update WD (git-pull), I think there is a problem with the python3-numpy package.
As you remember, during the WD installation on my fresh and clean Ubuntu 20.04 Laptop the python3-numpy package didn't install either and broke the install procedere... (same or similar problem ?)
Here is what the pi prints after trying to start WD:
What should I do ?
---------------------------------
pi@ON5KQ-Pi4:~/wsprdaemon $ ./wsprdaemon.sh -a
wsprdaemon.sh Copyright (C) 2020 Robert S. Robinett
This program comes with ABSOLUTELY NO WARRANTY; for details type './wsprdaemon.sh -h'
This is free software, and you are welcome to redistribute it under certain conditions. execute'./wsprdaemon.sh -h' for details.
wsprdaemon depends heavily upon the 'wsprd' program and other technologies developed by Joe Taylor K1JT and others, to whom we are grateful.
Goto https://physics.princeton.edu/pulsar/K1JT/wsjtx.html to learn more about WSJT-x
Currently installed version of kiwirecorder.py fails to run:
Traceback (most recent call last):
File "/home/pi/.local/lib/python3.7/site-packages/numpy/core/__init__.py", line 22, in <module>
from . import multiarray
File "/home/pi/.local/lib/python3.7/site-packages/numpy/core/multiarray.py", line 12, in <module>
from . import overrides
File "/home/pi/.local/lib/python3.7/site-packages/numpy/core/overrides.py", line 7, in <module>
from numpy.core._multiarray_umath import (
ImportError: libf77blas.so.3: cannot open shared object file: No such file or directory
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/pi/wsprdaemon/kiwiclient/kiwirecorder.py", line 7, in <module>
import numpy as np
File "/home/pi/.local/lib/python3.7/site-packages/numpy/__init__.py", line 140, in <module>
from . import core
File "/home/pi/.local/lib/python3.7/site-packages/numpy/core/__init__.py", line 48, in <module>
raise ImportError(msg)
ImportError:
IMPORTANT: PLEASE READ THIS FOR ADVICE ON HOW TO SOLVE THIS ISSUE!
Importing the numpy C-extensions failed. This error can happen for
many reasons, often due to issues with your setup or how NumPy was
installed.
We have compiled some common reasons and troubleshooting tips at:
https://numpy.org/devdocs/user/troubleshooting-importerror.html
Please note and check the following:
* The Python version is: Python3.7 from "/usr/bin/python3"
* The NumPy version is: "1.19.2"
and make sure that they are the versions you expect.
Please carefully study the documentation linked above for further help.
Original error was: libf77blas.so.3: cannot open shared object file: No such file or directory
Found unknown error in ./kiwiclient.log when running 'python3 /home/pi/wsprdaemon/kiwiclient/kiwirecorder.py'
pi@ON5KQ-Pi4:~/wsprdaemon $
------------------------------------------------
|
|
|
Ok, I did the following: run:
pip3 uninstall numpy # remove previously installed version
apt install python3-numpy
There are sometimes issues reported on Raspberry Pi setups when installing using pip3 install (or pip install). These will typically mention:
libf77blas.so.3: cannot open shared object file: No such file or directory
The solution will be to either:
sudo apt-get install libatlas-base-dev
to install the missing libraries expected by the self-compiled NumPy (ATLAS is a possible provider of linear algebra).
Now I tried again... at least WD seem to start on the raspberry without the previous fault message. WD connects the kiwi for just a simple schedule on 80m decode... however... NO UPLOADS at all, NO Decodes either...:
here is the check on uploads at the pi - as with verbosity 1 there was no reaction nor any info at all, I increased verbosity even more
So it seems the new decoder just don't nothing - if it doesn't decode anything the is no upload ...... however the band is full !!
How to switch back to the old decoder ?
--------
pi@ON5KQ-Pi4:~/wsprdaemon/uploads.d/wsprnet.d/spots.d $ ~/wsprdaemon/wsprdaemon.sh -d
wsprdaemon.sh Copyright (C) 2020 Robert S. Robinett
This program comes with ABSOLUTELY NO WARRANTY; for details type './wsprdaemon.sh -h'
This is free software, and you are welcome to redistribute it under certain conditions. execute'./wsprdaemon.sh -h' for details.
wsprdaemon depends heavily upon the 'wsprd' program and other technologies developed by Joe Taylor K1JT and others, to whom we are grateful.
Goto https://physics.princeton.edu/pulsar/K1JT/wsjtx.html to learn more about WSJT-x
Signaling verbosity change to PID 19568 from uploads.pid
pi@ON5KQ-Pi4:~/wsprdaemon/uploads.d/wsprnet.d/spots.d $ tail -f uploads.log
Sat 17 Oct 2020 08:56:40 AM UTC: verbosity_increment() verbosity now = 1
Sat 17 Oct 2020 08:59:20 AM UTC: verbosity_increment() verbosity now = 2
Sat 17 Oct 2020 08:59:20 AM UTC: upload_to_wsprnet_daemon() checking for spot files to upload in all running jobs directories
Sat 17 Oct 2020 08:59:20 AM UTC: upload_to_wsprnet_daemon() adding 'ON5KQ_JO10os' to list of CALL_GRIDs to be searched for spot files to upload
Sat 17 Oct 2020 08:59:20 AM UTC: upload_to_wsprnet_daemon() found 1 CALL_GRIDS to search for uploads: 'ON5KQ_JO10os'
Sat 17 Oct 2020 08:59:20 AM UTC: upload_to_wsprnet_daemon() adding band '80' to list for call ON5KQ grid JO10os
Sat 17 Oct 2020 08:59:20 AM UTC: upload_to_wsprnet_daemon() 'ON5KQ_JO10os' reports on bands '80' from jobs 'Vdip1,80'
Sat 17 Oct 2020 08:59:20 AM UTC: upload_to_wsprnet_daemon() checking running job 'Vdip1,80' spot directory /home/pi/wsprdaemon/uploads.d/wsprnet.d/spots.d/ON5KQ_JO10os/Vdip1/80
Sat 17 Oct 2020 08:59:20 AM UTC: upload_to_wsprnet_daemon() found no spot files in /home/pi/wsprdaemon/uploads.d/wsprnet.d/spots.d/ON5KQ_JO10os/Vdip1/80
Sat 17 Oct 2020 08:59:20 AM UTC: upload_to_wsprnet_daemon() sleeping for 10 seconds
Sat 17 Oct 2020 08:59:30 AM UTC: upload_to_wsprnet_daemon() checking for spot files to upload in all running jobs directories
Sat 17 Oct 2020 08:59:30 AM UTC: upload_to_wsprnet_daemon() adding 'ON5KQ_JO10os' to list of CALL_GRIDs to be searched for spot files to upload
Sat 17 Oct 2020 08:59:30 AM UTC: upload_to_wsprnet_daemon() found 1 CALL_GRIDS to search for uploads: 'ON5KQ_JO10os'
Sat 17 Oct 2020 08:59:30 AM UTC: upload_to_wsprnet_daemon() adding band '80' to list for call ON5KQ grid JO10os
Sat 17 Oct 2020 08:59:30 AM UTC: upload_to_wsprnet_daemon() 'ON5KQ_JO10os' reports on bands '80' from jobs 'Vdip1,80'
Sat 17 Oct 2020 08:59:30 AM UTC: upload_to_wsprnet_daemon() checking running job 'Vdip1,80' spot directory /home/pi/wsprdaemon/uploads.d/wsprnet.d/spots.d/ON5KQ_JO10os/Vdip1/80
Sat 17 Oct 2020 08:59:30 AM UTC: upload_to_wsprnet_daemon() found no spot files in /home/pi/wsprdaemon/uploads.d/wsprnet.d/spots.d/ON5KQ_JO10os/Vdip1/80
Sat 17 Oct 2020 08:59:30 AM UTC: upload_to_wsprnet_daemon() sleeping for 10 seconds
Sat 17 Oct 2020 08:59:40 AM UTC: upload_to_wsprnet_daemon() checking for spot files to upload in all running jobs directories
Sat 17 Oct 2020 08:59:40 AM UTC: upload_to_wsprnet_daemon() adding 'ON5KQ_JO10os' to list of CALL_GRIDs to be searched for spot files to upload
Sat 17 Oct 2020 08:59:40 AM UTC: upload_to_wsprnet_daemon() found 1 CALL_GRIDS to search for uploads: 'ON5KQ_JO10os'
Sat 17 Oct 2020 08:59:40 AM UTC: upload_to_wsprnet_daemon() adding band '80' to list for call ON5KQ grid JO10os
Sat 17 Oct 2020 08:59:40 AM UTC: upload_to_wsprnet_daemon() 'ON5KQ_JO10os' reports on bands '80' from jobs 'Vdip1,80'
Sat 17 Oct 2020 08:59:40 AM UTC: upload_to_wsprnet_daemon() checking running job 'Vdip1,80' spot directory /home/pi/wsprdaemon/uploads.d/wsprnet.d/spots.d/ON5KQ_JO10os/Vdip1/80
Sat 17 Oct 2020 08:59:40 AM UTC: upload_to_wsprnet_daemon() found no spot files in /home/pi/wsprdaemon/uploads.d/wsprnet.d/spots.d/ON5KQ_JO10os/Vdip1/80
Sat 17 Oct 2020 08:59:40 AM UTC: upload_to_wsprnet_daemon() sleeping for 10 seconds
Sat 17
|
|
|
Stopping WD on the pi4 produced this:
------------------------------------------
pi@ON5KQ-Pi4:~/wsprdaemon $ ./wsprdaemon.sh -z
wsprdaemon.sh Copyright (C) 2020 Robert S. Robinett
This program comes with ABSOLUTELY NO WARRANTY; for details type './wsprdaemon.sh -h'
This is free software, and you are welcome to redistribute it under certain conditions. execute'./wsprdaemon.sh -h' for details.
wsprdaemon depends heavily upon the 'wsprd' program and other technologies developed by Joe Taylor K1JT and others, to whom we are grateful.
Goto https://physics.princeton.edu/pulsar/K1JT/wsjtx.html to learn more about WSJT-x
./wsprdaemon.sh: line 220: 28169 Killed python3 ${KIWI_RECORD_COMMAND} --help 1>&${KIWI_RECORD_TMP_LOG_FILE}
Currently installed version of kiwirecorder.py fails to run:
Found unknown error in ./kiwiclient.log when running 'python3 /home/pi/wsprdaemon/kiwiclient/kiwirecorder.py'
pi@ON5KQ-Pi4:~/wsprdaemon $
-----------------------------
????
|
|
|
I switched off the kiwi and reboot it.
The fault message with the kiwirecorder (see above) disappeared.... however no decodes, no spots
The terminal "top -c" shows the wsprd executing and calculating rather long for 35sec only a single band (now switched to 40m most busy band for one channel simple schedule)
But after all the calculations no decode..
|
|
|
By the way - no problem with ntp.... the time of the Pi4 is exact...
|
|
|
At least I found one reason there is no spot nor upload:
with WD 2.10f it is a MUST to include in the .conf file the following:
JT9_DECODE_ENABLED="yes"
If you do not include it, wd don't decode anything...
I don't know, why JT9 is necessary for wspr-decoding....
Now there are decodes as well as uploads...
Ulli, ON5KQ
|
|
|
I have just checked in v2.10g which fixes the uninitialized variable bug which was causing recording jobs to abort.
There may be lurking missing library problems which I will explore next
|
|
|
Rob,
you may have realized yourself - decoding still doesn't work correctly!
If I include in the .conf file either
JT9_DECODE_ENABLED="yes" or
JT9_DECODE_ENABLED="no"
the decoding stops after 1min and truncates a large percentage of the decodes..
If I do not include at all the JT9 line it keeps decoding, but merging does not work correctly. For example I almost never get a good merge on 40m, instead the merge.log shows only one receiver decoding - the other receiver has stars... as if there was no antenna feeding it...
It could be, that it is just a fault of writing the merge.log file in the tmp folder. But at least there is no indication which receiver has heard what... the spots are only listed on ONE single receiver.
To make it more complicated it happens only in 70% of the many 2min periods. Sometimes all receives indeed show some decodes and there are no consistent stars at all but one.
I use 3 receiver channels on 40m,...
Also the noise chart doesn't plot correctly - with me it is mostly 40m, which is the problem. c2_level writes a value of 999
This happens if there is no JT9 line in the conf. file
However if I include the line, decoding time is cut to 1min, which is not enough.
This is just to try to explain what still is wrong here...
Ulli, ON5KQ
P.S. One more interesting observation: When I start WD, it starts to connect to the Kiwi's according to the schedule set in .conf file. However it does it not immediately. It starts with 2 or 3 channels... next 2min interval it takes 2 or 3 more, which were missing before....next 2min interval it takes 2 or 3 more, which were missing before...and so on... until all channels have been grabbed as configured... That looks very strange ! In the past with the old decoder, when I start WD, the script immediately grabbed the channels, which were configured - not anymore with the new version... Why is that ?
|
|
|
Hi Ulli,
I need ssh access to your WD server to diagnose your problem, but the public IP address you gave me no longer works.
Rob
On Mon, Oct 19, 2020 at 5:11 AM ON5KQ < ON5KQ@...> wrote: Rob,
you may have realized yourself - decoding still doesn't work correctly!
If I include in the .conf file either
JT9_DECODE_ENABLED="yes" or
JT9_DECODE_ENABLED="no"
the decoding stops after 1min and truncates a large percentage of the decodes..
If I do not include at all the JT9 line it keeps decoding, but merging does not work correctly. For example I almost never get a good merge on 40m, instead the merge.log shows only one receiver decoding - the other receiver has stars... as if there was no antenna feeding it...
It could be, that it is just a fault of writing the merge.log file in the tmp folder. But at least there is no indication which receiver has heard what... the spots are only listed on ONE single receiver.
To make it more complicated it happens only in 70% of the many 2min periods. Sometimes all receives indeed show some decodes and there are no consistent stars at all but one.
I use 3 receiver channels on 40m,...
Also the noise chart doesn't plot correctly - with me it is mostly 40m, which is the problem. c2_level writes a value of 999
This happens if there is no JT9 line in the conf. file
However if I include the line, decoding time is cut to 1min, which is not enough.
This is just to try to explain what still is wrong here...
Ulli, ON5KQ
P.S. One more interesting observation: When I start WD, it starts to connect to the Kiwi's according to the schedule set in .conf file. However it does it not immediately. It starts with 2 or 3 channels... next 2min interval it takes 2 or 3 more, which were missing before....next 2min interval it takes 2 or 3 more, which were missing before...and so on... until all channels have been grabbed as configured... That looks very strange ! In the past with the old decoder, when I start WD, the script immediately grabbed the channels, which were configured - not anymore with the new version... Why is that ?
-- Rob Robinett AI6VN mobile: +1 650 218 8896
|
|
|
