Re: performance wsprdaemon on a RPI3
Bryan Klofas
Hey Rob--
toggle quoted messageShow quoted text
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,
|
|
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:
--
|
|
Memory leak (Bullseye)
John
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
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.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 --
|
|
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.
toggle quoted messageShow quoted text
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:
|
|
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:
|
|
Re: wsprdaemon with SDRplay devices on Raspberry Pi 4
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.
|
|
Re: Rejected
Rob Robinett
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
--
|
|
Re: Rejected
Rob Robinett
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:
--
|
|
Rejected
Jim Lill
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
-Jim WA2ZKD
|
|
New -A and -Z command line options in WD 3.0.2
Rob Robinett
I almost always execute 'wd -a' to start WD and 'wd -z' to stop it.
However if you want to have WD start automatically after power-up or reboot, then execute 'wd -A'. It configures Linux to run WD at startup and then executes the 'systemctl start wsprdaemon' command which would run at that time. After 'WD -A' you can 'wd -s', 'wd -z' and 'wd -a' if you want to make changes to your config file. 'wd -Z' will disable the automatic startup by running 'systemctl stop wsprdaemon' and then 'systemctl disable wsprdaemon' so that WD will not run at startup
|
|
Re: FST4W and 22M now working in version 3.0.2
Rob Robinett
Hi Gerhard, I think you may need to stop your WD 2.10 before starting WD 3.0.2 If you are already doing that, then I would need ssh access to your odroid to further debug the problem. PM me if you want to give me remote access. Rob
On Sat, May 21, 2022 at 1:34 PM <gerhard@...> wrote:
--
|
|
Corrected and more informative wd_template.conf now available in 3.0.2
Rob Robinett
I have just checked in a revision of that file which (I hope) fixes a few errors and adds a much more detailed explanation of the settings in your wsprdaemon.conf
For those of you already running 3.0.2, execute 'git pull' to get the new wd_template.conf 'git pull' will never disturb your wsprdaemon.conf
|
|
Re: FST4W and 22M now working in version 3.0.2
@OE3GBB
Hi Rob, What I did since: Installed WD 2.10 on clean Odroid XU4 without problems and was runing 14 chanals over night. Now changed to v3.0 and the problem with reconnection to the SDR happend again. Found the following reports: odroid@odroid:~/wsprdaemon$ ./wsprdaemon.sh -l e Checking every 10 seconds for new ERROR lines in all the log files. Press <CONTROL C> to exit /tmp/wsprdaemon/recording.d/KIWI_0/80eu/decoding_daemon.log: Sat 21 May 2022 20:19:02 UTC: sleep_until_raw_file_is_full() ERROR: wav file stabilized at invalid too long duration 00:01:06.03, so there appear to be more than one instance of the KWR running. 'ps' output was: /tmp/wsprdaemon/recording.d/KIWI_0/80/wav_recording_daemon.log: Sat 21 May 2022 20:17:06 UTC: kiwirecorder_manager_daemon() ERROR: 'ps 2524' reports kiwirecorder.py is running, but there is no log file of its output, so 'kill 2524' and try to restart it /tmp/wsprdaemon/recording.d/KIWI_0/80/decoding_daemon.log: Sat 21 May 2022 20:19:02 UTC: sleep_until_raw_file_is_full() ERROR: wav file stabilized at invalid too long duration 00:01:06.03, so there appear to be more than one instance of the KWR running. 'ps' output was: /tmp/wsprdaemon/recording.d/KIWI_0/630/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: sleep_until_raw_file_is_full() ERROR: wav file stabilized at invalid too long duration 00:01:06.08, so there appear to be more than one instance of the KWR running. 'ps' output was: /tmp/wsprdaemon/recording.d/KIWI_0/60eu/decoding_daemon.log: Sat 21 May 2022 20:19:03 UTC: sleep_until_raw_file_is_full() ERROR: wav file stabilized at invalid too long duration 00:01:06.03, so there appear to be more than one instance of the KWR running. 'ps' output was: /tmp/wsprdaemon/recording.d/KIWI_0/60/decoding_daemon.log: Sat 21 May 2022 20:19:02 UTC: sleep_until_raw_file_is_full() ERROR: wav file stabilized at invalid too long duration 00:01:06.08, so there appear to be more than one instance of the KWR running. 'ps' output was: /tmp/wsprdaemon/recording.d/KIWI_0/40/decoding_daemon.log: Sat 21 May 2022 20:19:03 UTC: sleep_until_raw_file_is_full() ERROR: wav file stabilized at invalid too long duration 00:01:06.03, so there appear to be more than one instance of the KWR running. 'ps' output was: /tmp/wsprdaemon/recording.d/KIWI_0/30/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: sleep_until_raw_file_is_full() ERROR: wav file stabilized at invalid too long duration 00:01:06.03, so there appear to be more than one instance of the KWR running. 'ps' output was: Checking every 10 seconds for new ERROR lines in all the log files. Press <CONTROL C> to exit /tmp/wsprdaemon/recording.d/KIWI_0/80eu/decoding_daemon.log: Sat 21 May 2022 20:19:02 UTC: sleep_until_raw_file_is_full() ERROR: wav file stabilized at invalid too long duration 00:01:06.03, so there appear to be more than one instance of the KWR running. 'ps' output was: /tmp/wsprdaemon/recording.d/KIWI_0/80/wav_recording_daemon.log: Sat 21 May 2022 20:17:06 UTC: kiwirecorder_manager_daemon() ERROR: 'ps 2524' reports kiwirecorder.py is running, but there is no log file of its output, so 'kill 2524' and try to restart it /tmp/wsprdaemon/recording.d/KIWI_0/2200/decoding_daemon.log: Sat 21 May 2022 20:19:03 UTC: sleep_until_raw_file_is_full() ERROR: wav file stabilized at invalid too long duration 00:01:06.03, so there appear to be more than one instance of the KWR running. 'ps' output was: /tmp/wsprdaemon/recording.d/KIWI_0/20/decoding_daemon.log: Sat 21 May 2022 20:19:02 UTC: sleep_until_raw_file_is_full() ERROR: wav file stabilized at invalid too long duration 00:01:06.03, so there appear to be more than one instance of the KWR running. 'ps' output was: /tmp/wsprdaemon/recording.d/KIWI_0/17/decoding_daemon.log: Sat 21 May 2022 20:19:03 UTC: sleep_until_raw_file_is_full() ERROR: wav file stabilized at invalid too long duration 00:01:06.03, so there appear to be more than one instance of the KWR running. 'ps' output was: /tmp/wsprdaemon/recording.d/KIWI_0/160/decoding_daemon.log: Sat 21 May 2022 20:19:03 UTC: sleep_until_raw_file_is_full() ERROR: wav file stabilized at invalid too long duration 00:01:06.03, so there appear to be more than one instance of the KWR running. 'ps' output was: /tmp/wsprdaemon/recording.d/KIWI_0/80/decoding_daemon.log: Sat 21 May 2022 20:19:02 UTC: sleeSat 21 May 2022 20:22:49 UTC: wd_logger_check_all_logs() Found 13 new ERROR: lines /tmp/wsprdaemon/recording.d/KIWI_0/15/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: sleep_until_raw_file_is_full() ERROR: wav file stabilized at invalid too long duration 00:01:06.03, so there appear to be more than one instance of the KWR running. 'ps' output was: /tmp/wsprdaemon/recording.d/KIWI_0/12/decoding_daemon.log: Sat 21 May 2022 20:19:03 UTC: sleep_until_raw_file_is_full() ERROR: wav file stabilized at invalid too long duration 00:01:06.08, so there appear to be more than one instance of the KWR running. 'ps' output was: /tmp/wsprdaemon/recording.d/KIWI_0/10/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: sleep_until_raw_file_is_full() ERROR: wav file stabilized at invalid too long duration 00:01:06.08, so there appear to be more than one instance of the KWR running. 'ps' output was: There seems to be a problem with the wav-file. I am using Ubuntu with eMMC and external SSD drive, but same problem was seen on a RPi4 with SD-card. regards Gerhard OE3GBB Am 20.05.2022 16:21, schrieb Rob Robinett:
|
|
Re: WD 3.0.2.4 update adds improved support for 'noise level only' bands
Jim Lill
with CHU close by to NY.... we might find similar of use here
On 5/21/22 14:17, Rob Robinett wrote:
|
|