Date   

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
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

Checking every 10 seconds for new ERROR lines in all the log files. Press <CONTROL C> to exit
Sat 21 May 2022 20:20:04 UTC: wd_logger_check_all_logs() Found 8 new ERROR: lines
Sat 21 May 2022 20:20:04 UTC: wd_logger_check_all_logs() There are 8 new lines to be printed

/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/80eu/decoding_daemon.log: odroid 2679 4.0 0.9 35400 19512 ? Sl 20:17 0:04 python3 -u /home/odroid/wsprdaemon/kiwiclient/kiwirecorder.py --freq=3592.6 --server-host=192.168.1.196 --server-port=8073 --OV --user=wsprdaemon_v3.0.2 --password=NULL --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60
/tmp/wsprdaemon/recording.d/KIWI_0/80eu/decoding_daemon.log: So executed 'kill 2679'
/tmp/wsprdaemon/recording.d/KIWI_0/80eu/decoding_daemon.log: Sat 21 May 2022 20:19:02 UTC: get_wav_file_list() Error while waiting for the first wav file to fill, 'sleep_until_raw_file_is_full 20220521T201800Z_3592600_usb.wav' => 1
/tmp/wsprdaemon/recording.d/KIWI_0/80eu/decoding_daemon.log: Sat 21 May 2022 20:19:02 UTC: decoding_daemon() Error 2 returned by 'get_wav_file_list mode_wav_file_list KIWI_0 80eu W2'. 'sleep 1' and retry
/tmp/wsprdaemon/recording.d/KIWI_0/80eu/decoding_daemon.log: Sat 21 May 2022 20:19:03 UTC: get_wav_file_list() Start with args 'mode_seconds_files KIWI_0 80eu W2', then receiver_modes => W2 => target_minutes=( 2 ) => target_seconds=( 120 )
/tmp/wsprdaemon/recording.d/KIWI_0/80eu/decoding_daemon.log: Sat 21 May 2022 20:19:03 UTC: get_wav_file_list() Found raw/wav files '20220521T201800Z_3592600_usb.wav 20220521T201900Z_3592600_usb.wav 20220521T201903Z_3592600_usb.wav'
/tmp/wsprdaemon/recording.d/KIWI_0/80eu/decoding_daemon.log: Sat 21 May 2022 20:19:36 UTC: kill_wav_recording_daemon() killed KIWI_0 80eu job which had pid 2602
Press <ENTER> to check the next log file >
Sat 21 May 2022 20:20:14 UTC: wd_logger_check_all_logs() Found 8 new ERROR: lines
Sat 21 May 2022 20:20:14 UTC: wd_logger_check_all_logs() There are 8 new lines to be printed

/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/wav_recording_daemon.log: Sat 21 May 2022 20:17:07 UTC: kiwirecorder_manager_daemon() Spawning new /home/odroid/wsprdaemon/kiwiclient/kiwirecorder.py
/tmp/wsprdaemon/recording.d/KIWI_0/80/wav_recording_daemon.log: Sat 21 May 2022 20:17:07 UTC: kiwirecorder_manager_daemon() Spawned kiwirecorder.py job with PID 3098
/tmp/wsprdaemon/recording.d/KIWI_0/80/wav_recording_daemon.log: Sat 21 May 2022 20:19:04 UTC: kiwirecorder_manager_daemon() 'ps 3098' reports error:
/tmp/wsprdaemon/recording.d/KIWI_0/80/wav_recording_daemon.log: PID TTY STAT TIME COMMAND
/tmp/wsprdaemon/recording.d/KIWI_0/80/wav_recording_daemon.log: Sat 21 May 2022 20:19:04 UTC: kiwirecorder_manager_daemon() Spawning new /home/odroid/wsprdaemon/kiwiclient/kiwirecorder.py
/tmp/wsprdaemon/recording.d/KIWI_0/80/wav_recording_daemon.log: Sat 21 May 2022 20:19:04 UTC: kiwirecorder_manager_daemon() Spawned kiwirecorder.py job with PID 18435
/tmp/wsprdaemon/recording.d/KIWI_0/80/wav_recording_daemon.log: Sat 21 May 2022 20:19:35 UTC: kiwirecorder_manager_daemon_kill_handler() Killed kiwi_recorder_pid=18435
Press <ENTER> to check the next log file >
Sat 21 May 2022 20:20:21 UTC: wd_logger_check_all_logs() Found 13 new ERROR: lines
Sat 21 May 2022 20:20:21 UTC: wd_logger_check_all_logs() There are 13 new lines to be printed

/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/80/decoding_daemon.log: odroid 3098 4.5 0.9 35400 19488 ? Sl 20:17 0:05 python3 -u /home/odroid/wsprdaemon/kiwiclient/kiwirecorder.py --freq=3568.6 --server-host=192.168.1.196 --server-port=8073 --OV --user=wsprdaemon_v3.0.2 --password=NULL --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60
/tmp/wsprdaemon/recording.d/KIWI_0/80/decoding_daemon.log: So executed 'kill 3098'
/tmp/wsprdaemon/recording.d/KIWI_0/80/decoding_daemon.log: Sat 21 May 2022 20:19:02 UTC: get_wav_file_list() Error while waiting for the first wav file to fill, 'sleep_until_raw_file_is_full 20220521T201800Z_3568600_usb.wav' => 1
/tmp/wsprdaemon/recording.d/KIWI_0/80/decoding_daemon.log: Sat 21 May 2022 20:19:03 UTC: decoding_daemon() Error 2 returned by 'get_wav_file_list mode_wav_file_list KIWI_0 80 W2'. 'sleep 1' and retry
/tmp/wsprdaemon/recording.d/KIWI_0/80/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: get_wav_file_list() Start with args 'mode_seconds_files KIWI_0 80 W2', then receiver_modes => W2 => target_minutes=( 2 ) => target_seconds=( 120 )
/tmp/wsprdaemon/recording.d/KIWI_0/80/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: get_wav_file_list() Found raw/wav files '20220521T201800Z_3568600_usb.wav 20220521T201900Z_3568600_usb.wav'
/tmp/wsprdaemon/recording.d/KIWI_0/80/decoding_daemon.log: Sat 21 May 2022 20:19:06 UTC: sleep_until_raw_file_is_full() The wav file stabilized at invalid too short duration 00:00:03.14 which almost always occurs at startup. Flush this file since it can't be used as part of a WSPR wav file
Press <ENTER> to check the next log file >
Sat 21 May 2022 20:20:24 UTC: wd_logger_check_all_logs() Found 13 new ERROR: lines
Sat 21 May 2022 20:20:24 UTC: wd_logger_check_all_logs() There are 13 new lines to be printed

/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/630/decoding_daemon.log: odroid 2089 3.8 0.9 35400 19724 ? Sl 20:17 0:04 python3 -u /home/odroid/wsprdaemon/kiwiclient/kiwirecorder.py --freq=474.2 --server-host=192.168.1.196 --server-port=8073 --OV --user=wsprdaemon_v3.0.2 --password=NULL --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60
/tmp/wsprdaemon/recording.d/KIWI_0/630/decoding_daemon.log: So executed 'kill 2089'
/tmp/wsprdaemon/recording.d/KIWI_0/630/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: get_wav_file_list() Error while waiting for the first wav file to fill, 'sleep_until_raw_file_is_full 20220521T201800Z_474200_usb.wav' => 1
/tmp/wsprdaemon/recording.d/KIWI_0/630/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: decoding_daemon() Error 2 returned by 'get_wav_file_list mode_wav_file_list KIWI_0 630 W2'. 'sleep 1' and retry
/tmp/wsprdaemon/recording.d/KIWI_0/630/decoding_daemon.log: Sat 21 May 2022 20:19:05 UTC: get_wav_file_list() Start with args 'mode_seconds_files KIWI_0 630 W2', then receiver_modes => W2 => target_minutes=( 2 ) => target_seconds=( 120 )
/tmp/wsprdaemon/recording.d/KIWI_0/630/decoding_daemon.log: Sat 21 May 2022 20:19:06 UTC: get_wav_file_list() Found raw/wav files '20220521T201800Z_474200_usb.wav 20220521T201900Z_474200_usb.wav'
/tmp/wsprdaemon/recording.d/KIWI_0/630/decoding_daemon.log: Sat 21 May 2022 20:19:08 UTC: sleep_until_raw_file_is_full() The wav file stabilized at invalid too short duration 00:00:04.60 which almost always occurs at startup. Flush this file since it can't be used as part of a WSPR wav file
Press <ENTER> to check the next log file >
Sat 21 May 2022 20:20:25 UTC: wd_logger_check_all_logs() Found 13 new ERROR: lines
Sat 21 May 2022 20:20:25 UTC: wd_logger_check_all_logs() There are 13 new lines to be printed

/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/60eu/decoding_daemon.log: odroid 3176 4.2 0.9 35400 19628 ? Sl 20:17 0:04 python3 -u /home/odroid/wsprdaemon/kiwiclient/kiwirecorder.py --freq=5364.7 --server-host=192.168.1.196 --server-port=8073 --OV --user=wsprdaemon_v3.0.2 --password=NULL --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60
/tmp/wsprdaemon/recording.d/KIWI_0/60eu/decoding_daemon.log: So executed 'kill 3176'
/tmp/wsprdaemon/recording.d/KIWI_0/60eu/decoding_daemon.log: Sat 21 May 2022 20:19:03 UTC: get_wav_file_list() Error while waiting for the first wav file to fill, 'sleep_until_raw_file_is_full 20220521T201800Z_5364700_usb.wav' => 1
/tmp/wsprdaemon/recording.d/KIWI_0/60eu/decoding_daemon.log: Sat 21 May 2022 20:19:03 UTC: decoding_daemon() Error 2 returned by 'get_wav_file_list mode_wav_file_list KIWI_0 60eu W2'. 'sleep 1' and retry
/tmp/wsprdaemon/recording.d/KIWI_0/60eu/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: get_wav_file_list() Start with args 'mode_seconds_files KIWI_0 60eu W2', then receiver_modes => W2 => target_minutes=( 2 ) => target_seconds=( 120 )
/tmp/wsprdaemon/recording.d/KIWI_0/60eu/decoding_daemon.log: Sat 21 May 2022 20:19:05 UTC: get_wav_file_list() Found raw/wav files '20220521T201800Z_5364700_usb.wav 20220521T201900Z_5364700_usb.wav'
/tmp/wsprdaemon/recording.d/KIWI_0/60eu/decoding_daemon.log: Sat 21 May 2022 20:19:07 UTC: sleep_until_raw_file_is_full() The wav file stabilized at invalid too short duration 00:00:03.60 which almost always occurs at startup. Flush this file since it can't be used as part of a WSPR wav file
Press <ENTER> to check the next log file >
Sat 21 May 2022 20:20:26 UTC: wd_logger_check_all_logs() Found 13 new ERROR: lines
Sat 21 May 2022 20:20:26 UTC: wd_logger_check_all_logs() There are 13 new lines to be printed

/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/60/decoding_daemon.log: odroid 2953 4.0 0.9 35400 19528 ? Sl 20:17 0:04 python3 -u /home/odroid/wsprdaemon/kiwiclient/kiwirecorder.py --freq=5287.2 --server-host=192.168.1.196 --server-port=8073 --OV --user=wsprdaemon_v3.0.2 --password=NULL --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60
/tmp/wsprdaemon/recording.d/KIWI_0/60/decoding_daemon.log: So executed 'kill 2953'
/tmp/wsprdaemon/recording.d/KIWI_0/60/decoding_daemon.log: Sat 21 May 2022 20:19:02 UTC: get_wav_file_list() Error while waiting for the first wav file to fill, 'sleep_until_raw_file_is_full 20220521T201800Z_5287200_usb.wav' => 1
/tmp/wsprdaemon/recording.d/KIWI_0/60/decoding_daemon.log: Sat 21 May 2022 20:19:02 UTC: decoding_daemon() Error 2 returned by 'get_wav_file_list mode_wav_file_list KIWI_0 60 W2'. 'sleep 1' and retry
/tmp/wsprdaemon/recording.d/KIWI_0/60/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: get_wav_file_list() Start with args 'mode_seconds_files KIWI_0 60 W2', then receiver_modes => W2 => target_minutes=( 2 ) => target_seconds=( 120 )
/tmp/wsprdaemon/recording.d/KIWI_0/60/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: get_wav_file_list() Found raw/wav files '20220521T201800Z_5287200_usb.wav 20220521T201900Z_5287200_usb.wav'
/tmp/wsprdaemon/recording.d/KIWI_0/60/decoding_daemon.log: Sat 21 May 2022 20:19:06 UTC: sleep_until_raw_file_is_full() The wav file stabilized at invalid too short duration 00:00:03.09 which almost always occurs at startup. Flush this file since it can't be used as part of a WSPR wav file
Press <ENTER> to check the next log file >
Sat 21 May 2022 20:20:26 UTC: wd_logger_check_all_logs() Found 13 new ERROR: lines
Sat 21 May 2022 20:20:26 UTC: wd_logger_check_all_logs() There are 13 new lines to be printed

/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/40/decoding_daemon.log: odroid 3359 4.2 0.9 35400 19728 ? Sl 20:17 0:04 python3 -u /home/odroid/wsprdaemon/kiwiclient/kiwirecorder.py --freq=7038.6 --server-host=192.168.1.196 --server-port=8073 --OV --user=wsprdaemon_v3.0.2 --password=NULL --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60
/tmp/wsprdaemon/recording.d/KIWI_0/40/decoding_daemon.log: So executed 'kill 3359'
/tmp/wsprdaemon/recording.d/KIWI_0/40/decoding_daemon.log: Sat 21 May 2022 20:19:03 UTC: get_wav_file_list() Error while waiting for the first wav file to fill, 'sleep_until_raw_file_is_full 20220521T201800Z_7038600_usb.wav' => 1
/tmp/wsprdaemon/recording.d/KIWI_0/40/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: decoding_daemon() Error 2 returned by 'get_wav_file_list mode_wav_file_list KIWI_0 40 W2'. 'sleep 1' and retry
/tmp/wsprdaemon/recording.d/KIWI_0/40/decoding_daemon.log: Sat 21 May 2022 20:19:05 UTC: get_wav_file_list() Start with args 'mode_seconds_files KIWI_0 40 W2', then receiver_modes => W2 => target_minutes=( 2 ) => target_seconds=( 120 )
/tmp/wsprdaemon/recording.d/KIWI_0/40/decoding_daemon.log: Sat 21 May 2022 20:19:06 UTC: get_wav_file_list() Found raw/wav files '20220521T201800Z_7038600_usb.wav 20220521T201900Z_7038600_usb.wav'
/tmp/wsprdaemon/recording.d/KIWI_0/40/decoding_daemon.log: Sat 21 May 2022 20:19:08 UTC: sleep_until_raw_file_is_full() The wav file stabilized at invalid too short duration 00:00:04.14 which almost always occurs at startup. Flush this file since it can't be used as part of a WSPR wav file
Press <ENTER> to check the next log file >
Sat 21 May 2022 20:20:27 UTC: wd_logger_check_all_logs() Found 13 new ERROR: lines
Sat 21 May 2022 20:20:27 UTC: wd_logger_check_all_logs() There are 13 new lines to be printed

/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:
/tmp/wsprdaemon/recording.d/KIWI_0/30/decoding_daemon.log: odroid 3551 4.4 0.9 35400 19540 ? Sl 20:17 0:05 python3 -u /home/odroid/wsprdaemon/kiwiclient/kiwirecorder.py --freq=10138.7 --server-host=192.168.1.196 --server-port=8073 --OV --user=wsprdaemon_v3.0.2 --password=NULL --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60
/tmp/wsprdaemon/recording.d/KIWI_0/30/decoding_daemon.log: So executed 'kill 3551'
/tmp/wsprdaemon/recording.d/KIWI_0/30/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: get_wav_file_list() Error while waiting for the first wav file to fill, 'sleep_until_raw_file_is_full 20220521T201800Z_10138700_usb.wav' => 1
/tmp/wsprdaemon/recording.d/KIWI_0/30/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: decoding_daemon() Error 2 returned by 'get_wav_file_list mode_wav_file_list KIWI_0 30 W2'. 'sleep 1' and retry
/tmp/wsprdaemon/recording.d/KIWI_0/30/decoding_daemon.log: Sat 21 May 2022 20:19:05 UTC: get_wav_file_list() Start with args 'mode_seconds_files KIWI_0 30 W2', then receiver_modes => W2 => target_minutes=( 2 ) => target_seconds=( 120 )
/tmp/wsprdaemon/recording.d/KIWI_0/30/decoding_daemon.log: Sat 21 May 2022 20:19:06 UTC: get_wav_file_list() Found raw/wav files '20220521T201800Z_10138700_usb.wav 20220521T201900Z_10138700_usb.wav'
/tmp/wsprdaemon/recording.d/KIWI_0/30/decoding_daemon.log: Sat 21 May 2022 20:19:08 UTC: sleep_until_raw_file_is_full() The wav file stabilized at invalid too short duration 00:00:04.73 which almost always occurs at startup. Flush this file since it can't be used as part of a WSPR wav file
Press <ENTER> to check the next log file > odroid@odroid:~/wsprdaemon$ ./wsprdaemon.sh -l e
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

Checking every 10 seconds for new ERROR lines in all the log files. Press <CONTROL C> to exit
Sat 21 May 2022 20:20:04 UTC: wd_logger_check_all_logs() Found 8 new ERROR: lines
Sat 21 May 2022 20:20:04 UTC: wd_logger_check_all_logs() There are 8 new lines to be printed

/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/80eu/decoding_daemon.log: odroid 2679 4.0 0.9 35400 19512 ? Sl 20:17 0:04 python3 -u /home/odroid/wsprdaemon/kiwiclient/kiwirecorder.py --freq=3592.6 --server-host=192.168.1.196 --server-port=8073 --OV --user=wsprdaemon_v3.0.2 --password=NULL --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60
/tmp/wsprdaemon/recording.d/KIWI_0/80eu/decoding_daemon.log: So executed 'kill 2679'
/tmp/wsprdaemon/recording.d/KIWI_0/80eu/decoding_daemon.log: Sat 21 May 2022 20:19:02 UTC: get_wav_file_list() Error while waiting for the first wav file to fill, 'sleep_until_raw_file_is_full 20220521T201800Z_3592600_usb.wav' => 1
/tmp/wsprdaemon/recording.d/KIWI_0/80eu/decoding_daemon.log: Sat 21 May 2022 20:19:02 UTC: decoding_daemon() Error 2 returned by 'get_wav_file_list mode_wav_file_list KIWI_0 80eu W2'. 'sleep 1' and retry
/tmp/wsprdaemon/recording.d/KIWI_0/80eu/decoding_daemon.log: Sat 21 May 2022 20:19:03 UTC: get_wav_file_list() Start with args 'mode_seconds_files KIWI_0 80eu W2', then receiver_modes => W2 => target_minutes=( 2 ) => target_seconds=( 120 )
/tmp/wsprdaemon/recording.d/KIWI_0/80eu/decoding_daemon.log: Sat 21 May 2022 20:19:03 UTC: get_wav_file_list() Found raw/wav files '20220521T201800Z_3592600_usb.wav 20220521T201900Z_3592600_usb.wav 20220521T201903Z_3592600_usb.wav'
/tmp/wsprdaemon/recording.d/KIWI_0/80eu/decoding_daemon.log: Sat 21 May 2022 20:19:36 UTC: kill_wav_recording_daemon() killed KIWI_0 80eu job which had pid 2602
Press <ENTER> to check the next log file >
Sat 21 May 2022 20:20:14 UTC: wd_logger_check_all_logs() Found 8 new ERROR: lines
Sat 21 May 2022 20:20:14 UTC: wd_logger_check_all_logs() There are 8 new lines to be printed

/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/wav_recording_daemon.log: Sat 21 May 2022 20:17:07 UTC: kiwirecorder_manager_daemon() Spawning new /home/odroid/wsprdaemon/kiwiclient/kiwirecorder.py
/tmp/wsprdaemon/recording.d/KIWI_0/80/wav_recording_daemon.log: Sat 21 May 2022 20:17:07 UTC: kiwirecorder_manager_daemon() Spawned kiwirecorder.py job with PID 3098
/tmp/wsprdaemon/recording.d/KIWI_0/80/wav_recording_daemon.log: Sat 21 May 2022 20:19:04 UTC: kiwirecorder_manager_daemon() 'ps 3098' reports error:
/tmp/wsprdaemon/recording.d/KIWI_0/80/wav_recording_daemon.log: PID TTY STAT TIME COMMAND
/tmp/wsprdaemon/recording.d/KIWI_0/80/wav_recording_daemon.log: Sat 21 May 2022 20:19:04 UTC: kiwirecorder_manager_daemon() Spawning new /home/odroid/wsprdaemon/kiwiclient/kiwirecorder.py
/tmp/wsprdaemon/recording.d/KIWI_0/80/wav_recording_daemon.log: Sat 21 May 2022 20:19:04 UTC: kiwirecorder_manager_daemon() Spawned kiwirecorder.py job with PID 18435
/tmp/wsprdaemon/recording.d/KIWI_0/80/wav_recording_daemon.log: Sat 21 MSat 21 May 2022 20:22:48 UTC: wd_logger_check_all_logs() Found 13 new ERROR: lines
Sat 21 May 2022 20:22:48 UTC: wd_logger_check_all_logs() There are 13 new lines to be printed

/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/2200/decoding_daemon.log: odroid 1907 3.7 0.9 35400 19584 ? Sl 20:17 0:04 python3 -u /home/odroid/wsprdaemon/kiwiclient/kiwirecorder.py --freq=136.0 --server-host=192.168.1.196 --server-port=8073 --OV --user=wsprdaemon_v3.0.2 --password=NULL --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60
/tmp/wsprdaemon/recording.d/KIWI_0/2200/decoding_daemon.log: So executed 'kill 1907'
/tmp/wsprdaemon/recording.d/KIWI_0/2200/decoding_daemon.log: Sat 21 May 2022 20:19:03 UTC: get_wav_file_list() Error while waiting for the first wav file to fill, 'sleep_until_raw_file_is_full 20220521T201800Z_136000_usb.wav' => 1
/tmp/wsprdaemon/recording.d/KIWI_0/2200/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: decoding_daemon() Error 2 returned by 'get_wav_file_list mode_wav_file_list KIWI_0 2200 W2'. 'sleep 1' and retry
/tmp/wsprdaemon/recording.d/KIWI_0/2200/decoding_daemon.log: Sat 21 May 2022 20:19:05 UTC: get_wav_file_list() Start with args 'mode_seconds_files KIWI_0 2200 W2', then receiver_modes => W2 => target_minutes=( 2 ) => target_seconds=( 120 )
/tmp/wsprdaemon/recording.d/KIWI_0/2200/decoding_daemon.log: Sat 21 May 2022 20:19:06 UTC: get_wav_file_list() Found raw/wav files '20220521T201800Z_136000_usb.wav 20220521T201900Z_136000_usb.wav'
/tmp/wsprdaemon/recording.d/KIWI_0/2200/decoding_daemon.log: Sat 21 May 2022 20:19:08 UTC: sleep_until_raw_file_is_full() The wav file stabilized at invalid too short duration 00:00:04.14 which almost always occurs at startup. Flush this file since it can't be used as part of a WSPR wav file
Press <ENTER> to check the next log file > ay 2022 20:19:35 UTC: kiwirecorder_manager_daemon_kilSat 21 May 2022 20:22:49 UTC: wd_logger_check_all_logs() Found 13 new ERROR: lines
Sat 21 May 2022 20:22:49 UTC: wd_logger_check_all_logs() There are 13 new lines to be printed

/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/20/decoding_daemon.log: odroid 3834 4.4 0.9 35400 19664 ? Sl 20:17 0:05 python3 -u /home/odroid/wsprdaemon/kiwiclient/kiwirecorder.py --freq=14095.6 --server-host=192.168.1.196 --server-port=8073 --OV --user=wsprdaemon_v3.0.2 --password=NULL --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60
/tmp/wsprdaemon/recording.d/KIWI_0/20/decoding_daemon.log: So executed 'kill 3834'
/tmp/wsprdaemon/recording.d/KIWI_0/20/decoding_daemon.log: Sat 21 May 2022 20:19:02 UTC: get_wav_file_list() Error while waiting for the first wav file to fill, 'sleep_until_raw_file_is_full 20220521T201800Z_14095600_usb.wav' => 1
/tmp/wsprdaemon/recording.d/KIWI_0/20/decoding_daemon.log: Sat 21 May 2022 20:19:02 UTC: decoding_daemon() Error 2 returned by 'get_wav_file_list mode_wav_file_list KIWI_0 20 W2'. 'sleep 1' and retry
/tmp/wsprdaemon/recording.d/KIWI_0/20/decoding_daemon.log: Sat 21 May 2022 20:19:03 UTC: get_wav_file_list() Start with args 'mode_seconds_files KIWI_0 20 W2', then receiver_modes => W2 => target_minutes=( 2 ) => target_seconds=( 120 )
/tmp/wsprdaemon/recording.d/KIWI_0/20/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: get_wav_file_list() Found raw/wav files '20220521T201800Z_14095600_usb.wav 20220521T201900Z_14095600_usb.wav'
/tmp/wsprdaemon/recording.d/KIWI_0/20/decoding_daemon.log: Sat 21 May 2022 20:19:06 UTC: sleep_until_raw_file_is_full() The wav file stabilized at invalid too short duration 00:00:02.91 which almost always occurs at startup. Flush this file since it can't be used as part of a WSPR wav file
Press <ENTER> to check the next log file > l_handler() Killed kiwi_recorder_pid=18435
Press <ENTER> to check the next log file >
Sat 21 May 2022 20:22:49 UTC: wd_logger_check_all_logs() Found 13 new ERROR: lines
Sat 21 May 2022 20:22:49 UTC: wd_logger_check_all_logs() There are 13 new lines to be printed

/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/17/decoding_daemon.log: odroid 4067 4.4 0.9 35400 19508 ? Sl 20:17 0:05 python3 -u /home/odroid/wsprdaemon/kiwiclient/kiwirecorder.py --freq=18104.6 --server-host=192.168.1.196 --server-port=8073 --OV --user=wsprdaemon_v3.0.2 --password=NULL --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60
/tmp/wsprdaemon/recording.d/KIWI_0/17/decoding_daemon.log: So executed 'kill 4067'
/tmp/wsprdaemon/recording.d/KIWI_0/17/decoding_daemon.log: Sat 21 May 2022 20:19:03 UTC: get_wav_file_list() Error while waiting for the first wav file to fill, 'sleep_until_raw_file_is_full 20220521T201800Z_18104600_usb.wav' => 1
/tmp/wsprdaemon/recording.d/KIWI_0/17/decoding_daemon.log: Sat 21 May 2022 20:19:03 UTC: decoding_daemon() Error 2 returned by 'get_wav_file_list mode_wav_file_list KIWI_0 17 W2'. 'sleep 1' and retry
/tmp/wsprdaemon/recording.d/KIWI_0/17/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: get_wav_file_list() Start with args 'mode_seconds_files KIWI_0 17 W2', then receiver_modes => W2 => target_minutes=( 2 ) => target_seconds=( 120 )
/tmp/wsprdaemon/recording.d/KIWI_0/17/decoding_daemon.log: Sat 21 May 2022 20:19:05 UTC: get_wav_file_list() Found raw/wav files '20220521T201800Z_18104600_usb.wav 20220521T201900Z_18104600_usb.wav'
/tmp/wsprdaemon/recording.d/KIWI_0/17/decoding_daemon.log: Sat 21 May 2022 20:19:07 UTC: sleep_until_raw_file_is_full() The wav file stabilized at invalid too short duration 00:00:03.55 which almost always occurs at startup. Flush this file since it can't be used as part of a WSPR wav file
Press <ENTER> to check the next log file > Sat 21 May 2022 20:20:21 UTC: wd_logger_check_all_logs() Found 13 new ERROR: lines
Sat 21 May 2022 20:20:21 UTC: wd_logger_check_aSat 21 May 2022 20:22:49 UTC: wd_logger_check_all_logs() Found 13 new ERROR: lines
Sat 21 May 2022 20:22:49 UTC: wd_logger_check_all_logs() There are 13 new lines to be printed

/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/160/decoding_daemon.log: odroid 2316 4.1 0.9 35400 19660 ? Sl 20:17 0:04 python3 -u /home/odroid/wsprdaemon/kiwiclient/kiwirecorder.py --freq=1836.6 --server-host=192.168.1.196 --server-port=8073 --OV --user=wsprdaemon_v3.0.2 --password=NULL --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60
/tmp/wsprdaemon/recording.d/KIWI_0/160/decoding_daemon.log: So executed 'kill 2316'
/tmp/wsprdaemon/recording.d/KIWI_0/160/decoding_daemon.log: Sat 21 May 2022 20:19:03 UTC: get_wav_file_list() Error while waiting for the first wav file to fill, 'sleep_until_raw_file_is_full 20220521T201800Z_1836600_usb.wav' => 1
/tmp/wsprdaemon/recording.d/KIWI_0/160/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: decoding_daemon() Error 2 returned by 'get_wav_file_list mode_wav_file_list KIWI_0 160 W2'. 'sleep 1' and retry
/tmp/wsprdaemon/recording.d/KIWI_0/160/decoding_daemon.log: Sat 21 May 2022 20:19:05 UTC: get_wav_file_list() Start with args 'mode_seconds_files KIWI_0 160 W2', then receiver_modes => W2 => target_minutes=( 2 ) => target_seconds=( 120 )
/tmp/wsprdaemon/recording.d/KIWI_0/160/decoding_daemon.log: Sat 21 May 2022 20:19:06 UTC: get_wav_file_list() Found raw/wav files '20220521T201800Z_1836600_usb.wav 20220521T201900Z_1836600_usb.wav'
/tmp/wsprdaemon/recording.d/KIWI_0/160/decoding_daemon.log: Sat 21 May 2022 20:19:08 UTC: sleep_until_raw_file_is_full() The wav file stabilized at invalid too short duration 00:00:04.19 which almost always occurs at startup. Flush this file since it can't be used as part of a WSPR wav file
Press <ENTER> to check the next log file > ll_logs() There are 13 new lines to be printed

/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
Sat 21 May 2022 20:22:49 UTC: wd_logger_check_all_logs() There are 13 new lines to be printed

/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/15/decoding_daemon.log: odroid 4247 4.5 0.9 35400 19636 ? Sl 20:17 0:05 python3 -u /home/odroid/wsprdaemon/kiwiclient/kiwirecorder.py --freq=21094.6 --server-host=192.168.1.196 --server-port=8073 --OV --user=wsprdaemon_v3.0.2 --password=NULL --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60
/tmp/wsprdaemon/recording.d/KIWI_0/15/decoding_daemon.log: So executed 'kill 4247'
/tmp/wsprdaemon/recording.d/KIWI_0/15/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: get_wav_file_list() Error while waiting for the first wav file to fill, 'sleep_until_raw_file_is_full 20220521T201800Z_21094600_usb.wav' => 1
/tmp/wsprdaemon/recording.d/KIWI_0/15/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: decoding_daemon() Error 2 returned by 'get_wav_file_list mode_wav_file_list KIWI_0 15 W2'. 'sleep 1' and retry
/tmp/wsprdaemon/recording.d/KIWI_0/15/decoding_daemon.log: Sat 21 May 2022 20:19:05 UTC: get_wav_file_list() Start with args 'mode_seconds_files KIWI_0 15 W2', then receiver_modes => W2 => target_minutes=( 2 ) => target_seconds=( 120 )
/tmp/wsprdaemon/recording.d/KIWI_0/15/decoding_daemon.log: Sat 21 May 2022 20:19:06 UTC: get_wav_file_list() Found raw/wav files '20220521T201800Z_21094600_usb.wav 20220521T201900Z_21094600_usb.wav'
/tmp/wsprdaemon/recording.d/KIWI_0/15/decoding_daemon.log: Sat 21 May 2022 20:19:08 UTC: sleep_until_raw_file_is_full() The wav file stabilized at invalid too short duration 00:00:04.28 which almost always occurs at startup. Flush this file since it can't be used as part of a WSPR wav file
Press <ENTER> to check the next log file > p_until_raw_file_is_full() ERROR: wav file stabilized at invalid too long duration 00Sat 21 May 2022 20:22:49 UTC: wd_logger_check_all_logs() Found 13 new ERROR: lines
Sat 21 May 2022 20:22:49 UTC: wd_logger_check_all_logs() There are 13 new lines to be printed

/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/12/decoding_daemon.log: odroid 4422 4.5 0.9 35400 19624 ? Sl 20:17 0:05 python3 -u /home/odroid/wsprdaemon/kiwiclient/kiwirecorder.py --freq=24924.6 --server-host=192.168.1.196 --server-port=8073 --OV --user=wsprdaemon_v3.0.2 --password=NULL --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60
/tmp/wsprdaemon/recording.d/KIWI_0/12/decoding_daemon.log: So executed 'kill 4422'
/tmp/wsprdaemon/recording.d/KIWI_0/12/decoding_daemon.log: Sat 21 May 2022 20:19:03 UTC: get_wav_file_list() Error while waiting for the first wav file to fill, 'sleep_until_raw_file_is_full 20220521T201800Z_24924600_usb.wav' => 1
/tmp/wsprdaemon/recording.d/KIWI_0/12/decoding_daemon.log: Sat 21 May 2022 20:19:03 UTC: decoding_daemon() Error 2 returned by 'get_wav_file_list mode_wav_file_list KIWI_0 12 W2'. 'sleep 1' and retry
/tmp/wsprdaemon/recording.d/KIWI_0/12/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: get_wav_file_list() Start with args 'mode_seconds_files KIWI_0 12 W2', then receiver_modes => W2 => target_minutes=( 2 ) => target_seconds=( 120 )
/tmp/wsprdaemon/recording.d/KIWI_0/12/decoding_daemon.log: Sat 21 May 2022 20:19:05 UTC: get_wav_file_list() Found raw/wav files '20220521T201800Z_24924600_usb.wav 20220521T201900Z_24924600_usb.wav'
/tmp/wsprdaemon/recording.d/KIWI_0/12/decoding_daemon.log: Sat 21 May 2022 20:19:07 UTC: sleep_until_raw_file_is_full() The wav file stabilized at invalid too short duration 00:00:03.55 which almost always occurs at startup. Flush this file since it can't be used as part of a WSPR wav file
Press <ENTER> to check the next log file > :Sat 21 May 2022 20:22:49 UTC: wd_logger_check_all_logs() Found 13 new ERROR: lines
Sat 21 May 2022 20:22:49 UTC: wd_logger_check_all_logs() There are 13 new lines to be printed

/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:
/tmp/wsprdaemon/recording.d/KIWI_0/10/decoding_daemon.log: odroid 4511 4.4 0.9 35400 19520 ? Sl 20:17 0:05 python3 -u /home/odroid/wsprdaemon/kiwiclient/kiwirecorder.py --freq=28124.6 --server-host=192.168.1.196 --server-port=8073 --OV --user=wsprdaemon_v3.0.2 --password=NULL --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60
/tmp/wsprdaemon/recording.d/KIWI_0/10/decoding_daemon.log: So executed 'kill 4511'
/tmp/wsprdaemon/recording.d/KIWI_0/10/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: get_wav_file_list() Error while waiting for the first wav file to fill, 'sleep_until_raw_file_is_full 20220521T201800Z_28124600_usb.wav' => 1
/tmp/wsprdaemon/recording.d/KIWI_0/10/decoding_daemon.log: Sat 21 May 2022 20:19:04 UTC: decoding_daemon() Error 2 returned by 'get_wav_file_list mode_wav_file_list KIWI_0 10 W2'. 'sleep 1' and retry
/tmp/wsprdaemon/recording.d/KIWI_0/10/decoding_daemon.log: Sat 21 May 2022 20:19:05 UTC: get_wav_file_list() Start with args 'mode_seconds_files KIWI_0 10 W2', then receiver_modes => W2 => target_minutes=( 2 ) => target_seconds=( 120 )
/tmp/wsprdaemon/recording.d/KIWI_0/10/decoding_daemon.log: Sat 21 May 2022 20:19:06 UTC: get_wav_file_list() Found raw/wav files '20220521T201800Z_28124600_usb.wav 20220521T201900Z_28124600_usb.wav'
/tmp/wsprdaemon/recording.d/KIWI_0/10/decoding_daemon.log: Sat 21 May 2022 20:19:08 UTC: sleep_until_raw_file_is_full() The wav file stabilized at invalid too short duration 00:00:04.32 which almost always occurs at startup. Flush this file since it can't be used as part of a WSPR wav file
Press <ENTER> to check the next log file > 01:06.03, so there appear to be more than one instance of the KWR running. 'ps' output was:
/tm

 




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:

run 'wsprdaemon.sh -l e' and you will see all log lines with "ERROR ..."
they might give you a clue as to why your system isn't working.

On Fri, May 20, 2022 at 7:06 AM <gerhard@...> wrote:

Hi,

 

Have installed V3.0 first on the odroid XU4 (Ubuntu). Istallation seems to be OK, but did not work. The connection to the SDR is allways broken right after 2 minutes. Therefore no decoding and upload. SDR is a Flydog-SDR.

Then tried it on a RPi4, but unfortunatly same problem.

Had to stop now to go to a club reunion.

Will try it tomorrow with a Rasp_SDR.

73 Gerhard OE3GBB

 


Am 20.05.2022 15:23, schrieb Rob Robinett:

I know that in the recent past Jim WA2ZKD has installed WD on his odroid systems.
WD 3.0 includes the option for you to configure it to give me remote access if you need installation help.

On Fri, May 20, 2022 at 3:45 AM <gerhard@...> wrote:

Hello Rob,

great news! I am running the monitor at OE3XOE, at the moment using DigiSkimmer for WSPR and FT8. I will try V3, but I would like to use a Odroid XU4 instead a RPI4. Do you have instructions to install on this hardware?

73 de Gerhard OE3GBB

 


Am 20.05.2022 06:53, schrieb Rob Robinett:

The new Wsprdaemon version 3.0 software running on 20 sites from Maui to Europe is configured to simultaneously decode and report to wsprnet.org WSPR-2 and all of the FST4W-xxx modes on 630M and 160M. i.e. only one Kiwi rx channel is needed to decode all of the modes in every WSPR cycle.

While Spring and Summer are not optimal for those bands, I am seeing FST4W-120, -300 -900 and -1800 spots in Europe and on the East Coast.

On 2200M AI6VN/KH6 in Maui, N6GN in Colorado, and WA2TP in New York are decoding all the FST4W modes.

I expect that soon many the 50+ top spotting stations will be running Wsprdaemon Version 3.0 and extend FST4W listening coverage worldwide.

Hopefully that many FST4W listeners will encourage 2200/630/160 beacons to start transmitting in those modes

The Pi4 has just enough CPU to decode all 15 WSPR (i.e. 22M) bands and all of the FST4W modes on 2200/630/160M.

'git checkout 3.0.2' will get you the latest build (currently 3.0.2.4)
It is compatible with your existing config files, but to decode FST4W modes you will need to add specifications for them to your schedule.




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




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


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:

 In response to a user request, have tested and checked in enhancements to 3.0.2.4 which add support for the feature you requested which runs the quickest wsprd on those 'noise level only' bands like WWV_10.  You can see the noise level charts produced for those bands like WWV_10 at: http://wsprdaemon.org/graphs/NorthernUtahSDR/

In your conf file schedule you can explicitly define  mode 'W0"  (that is a zero) , e.g. "00:00 KIWI1,WWV_10,W0"
But W0 is now the default mode for those bands, so "00:00 KIWI1,WWV_10" defaults to W0.
Since this mode is a pure enhancement of  the functionality of 3.0.2.4 and (I think) the NortherUtahSDR (KA7OEI-1) site is the only user of those WWV_x bands, I haven't incremented the version number.

So if you run 'git pull' on a WD directory in which 'git checkout 3.0.2' has been run, you will see several files updated.  But if you don't have one of those WWV_x bands defined in your schedule, there should be no change in the operation of your site.


WD 3.0.2.4 update adds improved support for 'noise level only' bands

Rob Robinett
 

 In response to a user request, have tested and checked in enhancements to 3.0.2.4 which add support for the feature you requested which runs the quickest wsprd on those 'noise level only' bands like WWV_10.  You can see the noise level charts produced for those bands like WWV_10 at: http://wsprdaemon.org/graphs/NorthernUtahSDR/

In your conf file schedule you can explicitly define  mode 'W0"  (that is a zero) , e.g. "00:00 KIWI1,WWV_10,W0"
But W0 is now the default mode for those bands, so "00:00 KIWI1,WWV_10" defaults to W0.
Since this mode is a pure enhancement of  the functionality of 3.0.2.4 and (I think) the NortherUtahSDR (KA7OEI-1) site is the only user of those WWV_x bands, I haven't incremented the version number.

So if you run 'git pull' on a WD directory in which 'git checkout 3.0.2' has been run, you will see several files updated.  But if you don't have one of those WWV_x bands defined in your schedule, there should be no change in the operation of your site.


Re: WD 3.0 beta testing

Hidehiko Komachi - JA9MAT
 

Thanks dear Rob,

OK all I'm looking forward to apply RTL-SDR.

73, Hidehiko JA9MAT


Re: WD 3.0 beta testing

Rob Robinett
 

I'm sorry but it is a completely untested feature and I was unable to find a driver which could tune the RTL with sufficient accuracy for WSPR decoding.


On Fri, May 20, 2022 at 7:14 PM Hidehiko Komachi - JA9MAT <qrper72@...> wrote:
Hello,

I'd like to test RTL-SDR on WD 3.0 beta version.
Is this avairable now?

Hidehiko JA9MAT



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


Re: WD 3.0 beta testing

Hidehiko Komachi - JA9MAT
 

Hello,

I'd like to test RTL-SDR on WD 3.0 beta version.
Is this avairable now?

Hidehiko JA9MAT


Re: FST4W and 22M now working in version 3.0.2

Rob Robinett
 

run 'wsprdaemon.sh -l e' and you will see all log lines with "ERROR ..."
they might give you a clue as to why your system isn't working.

On Fri, May 20, 2022 at 7:06 AM <gerhard@...> wrote:

Hi,

 

Have installed V3.0 first on the odroid XU4 (Ubuntu). Istallation seems to be OK, but did not work. The connection to the SDR is allways broken right after 2 minutes. Therefore no decoding and upload. SDR is a Flydog-SDR.

Then tried it on a RPi4, but unfortunatly same problem.

Had to stop now to go to a club reunion.

Will try it tomorrow with a Rasp_SDR.

73 Gerhard OE3GBB

 


Am 20.05.2022 15:23, schrieb Rob Robinett:

I know that in the recent past Jim WA2ZKD has installed WD on his odroid systems.
WD 3.0 includes the option for you to configure it to give me remote access if you need installation help.

On Fri, May 20, 2022 at 3:45 AM <gerhard@...> wrote:

Hello Rob,

great news! I am running the monitor at OE3XOE, at the moment using DigiSkimmer for WSPR and FT8. I will try V3, but I would like to use a Odroid XU4 instead a RPI4. Do you have instructions to install on this hardware?

73 de Gerhard OE3GBB

 


Am 20.05.2022 06:53, schrieb Rob Robinett:

The new Wsprdaemon version 3.0 software running on 20 sites from Maui to Europe is configured to simultaneously decode and report to wsprnet.org WSPR-2 and all of the FST4W-xxx modes on 630M and 160M. i.e. only one Kiwi rx channel is needed to decode all of the modes in every WSPR cycle.

While Spring and Summer are not optimal for those bands, I am seeing FST4W-120, -300 -900 and -1800 spots in Europe and on the East Coast.

On 2200M AI6VN/KH6 in Maui, N6GN in Colorado, and WA2TP in New York are decoding all the FST4W modes.

I expect that soon many the 50+ top spotting stations will be running Wsprdaemon Version 3.0 and extend FST4W listening coverage worldwide.

Hopefully that many FST4W listeners will encourage 2200/630/160 beacons to start transmitting in those modes

The Pi4 has just enough CPU to decode all 15 WSPR (i.e. 22M) bands and all of the FST4W modes on 2200/630/160M.

'git checkout 3.0.2' will get you the latest build (currently 3.0.2.4)
It is compatible with your existing config files, but to decode FST4W modes you will need to add specifications for them to your schedule.




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



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


Re: FST4W and 22M now working in version 3.0.2

@OE3GBB
 

Hi,

 

Have installed V3.0 first on the odroid XU4 (Ubuntu). Istallation seems to be OK, but did not work. The connection to the SDR is allways broken right after 2 minutes. Therefore no decoding and upload. SDR is a Flydog-SDR.

Then tried it on a RPi4, but unfortunatly same problem.

Had to stop now to go to a club reunion.

Will try it tomorrow with a Rasp_SDR.

73 Gerhard OE3GBB

 


Am 20.05.2022 15:23, schrieb Rob Robinett:

I know that in the recent past Jim WA2ZKD has installed WD on his odroid systems.
WD 3.0 includes the option for you to configure it to give me remote access if you need installation help.

On Fri, May 20, 2022 at 3:45 AM <gerhard@...> wrote:

Hello Rob,

great news! I am running the monitor at OE3XOE, at the moment using DigiSkimmer for WSPR and FT8. I will try V3, but I would like to use a Odroid XU4 instead a RPI4. Do you have instructions to install on this hardware?

73 de Gerhard OE3GBB

 


Am 20.05.2022 06:53, schrieb Rob Robinett:

The new Wsprdaemon version 3.0 software running on 20 sites from Maui to Europe is configured to simultaneously decode and report to wsprnet.org WSPR-2 and all of the FST4W-xxx modes on 630M and 160M. i.e. only one Kiwi rx channel is needed to decode all of the modes in every WSPR cycle.

While Spring and Summer are not optimal for those bands, I am seeing FST4W-120, -300 -900 and -1800 spots in Europe and on the East Coast.

On 2200M AI6VN/KH6 in Maui, N6GN in Colorado, and WA2TP in New York are decoding all the FST4W modes.

I expect that soon many the 50+ top spotting stations will be running Wsprdaemon Version 3.0 and extend FST4W listening coverage worldwide.

Hopefully that many FST4W listeners will encourage 2200/630/160 beacons to start transmitting in those modes

The Pi4 has just enough CPU to decode all 15 WSPR (i.e. 22M) bands and all of the FST4W modes on 2200/630/160M.

'git checkout 3.0.2' will get you the latest build (currently 3.0.2.4)
It is compatible with your existing config files, but to decode FST4W modes you will need to add specifications for them to your schedule.




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


Re: FST4W and 22M now working in version 3.0.2

Rob Robinett
 

Look in wd_template.conf for explanations of the format.
During startup WD now checks that there is enough space in the tmpfs /tmp/wsprdaemon file system for the wav files recordings


### Following the time are one or more fields of the format 'RECEIVER,BAND[,MODE_1[:MODE_2[:...]]'

### The optional 'MODE' arguments specify one or more packet decode modes:
###    W2     => legacy WSPR 2 minute mode (the default if no modes are specified)
###    F2     => FST4W-120  (2 minute)
###    F5     => FST4W-300  (5 minute)
###    F15    => FST4W-900  (15 minue)
###    F30    => FST4W-1800 (30 minute)
###  For example "00:00   KIWI_0,630,W2:F2:F5  AI6VN"   specifies that KIWI_0 should tune to 630M and decode WSPR-2,FST4W-120, and FST4W-300 mode packets
###  Specifying additional modes will add to the CPU burden of the system and even more significantly to the peak usage of the /tmp/wsprdaemon tmpfs (ramdisk) file system
###  So if you specify F5/15/30 modes, run 'df /tmp/wsprdaemon' while running WD and adjust the size of /tmp/wsprdaemon in /etc/fstab to ensure there is at least 20% free space at all times


On Fri, May 20, 2022 at 6:40 AM John <johnk5mo@...> wrote:
Hi Rob

3.0.2 has been running drama-free on my Pi4 here.  I will look to see what is needed to enable  FST4W. Is there a sample config or a README to help?

John K5MO

On Fri, May 20, 2022 at 9:24 AM Rob Robinett <rob@...> wrote:
I know that in the recent past Jim WA2ZKD has installed WD on his odroid systems.
WD 3.0 includes the option for you to configure it to give me remote access if you need installation help.

On Fri, May 20, 2022 at 3:45 AM <gerhard@...> wrote:

Hello Rob,

great news! I am running the monitor at OE3XOE, at the moment using DigiSkimmer for WSPR and FT8. I will try V3, but I would like to use a Odroid XU4 instead a RPI4. Do you have instructions to install on this hardware?

73 de Gerhard OE3GBB

 


Am 20.05.2022 06:53, schrieb Rob Robinett:

The new Wsprdaemon version 3.0 software running on 20 sites from Maui to Europe is configured to simultaneously decode and report to wsprnet.org WSPR-2 and all of the FST4W-xxx modes on 630M and 160M. i.e. only one Kiwi rx channel is needed to decode all of the modes in every WSPR cycle.

While Spring and Summer are not optimal for those bands, I am seeing FST4W-120, -300 -900 and -1800 spots in Europe and on the East Coast.

On 2200M AI6VN/KH6 in Maui, N6GN in Colorado, and WA2TP in New York are decoding all the FST4W modes.

I expect that soon many the 50+ top spotting stations will be running Wsprdaemon Version 3.0 and extend FST4W listening coverage worldwide.

Hopefully that many FST4W listeners will encourage 2200/630/160 beacons to start transmitting in those modes

The Pi4 has just enough CPU to decode all 15 WSPR (i.e. 22M) bands and all of the FST4W modes on 2200/630/160M.

'git checkout 3.0.2' will get you the latest build (currently 3.0.2.4)
It is compatible with your existing config files, but to decode FST4W modes you will need to add specifications for them to your schedule.



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



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


Re: FST4W and 22M now working in version 3.0.2

John K5MO
 

Hi Rob

3.0.2 has been running drama-free on my Pi4 here.  I will look to see what is needed to enable  FST4W. Is there a sample config or a README to help?

John K5MO


On Fri, May 20, 2022 at 9:24 AM Rob Robinett <rob@...> wrote:
I know that in the recent past Jim WA2ZKD has installed WD on his odroid systems.
WD 3.0 includes the option for you to configure it to give me remote access if you need installation help.

On Fri, May 20, 2022 at 3:45 AM <gerhard@...> wrote:

Hello Rob,

great news! I am running the monitor at OE3XOE, at the moment using DigiSkimmer for WSPR and FT8. I will try V3, but I would like to use a Odroid XU4 instead a RPI4. Do you have instructions to install on this hardware?

73 de Gerhard OE3GBB

 


Am 20.05.2022 06:53, schrieb Rob Robinett:

The new Wsprdaemon version 3.0 software running on 20 sites from Maui to Europe is configured to simultaneously decode and report to wsprnet.org WSPR-2 and all of the FST4W-xxx modes on 630M and 160M. i.e. only one Kiwi rx channel is needed to decode all of the modes in every WSPR cycle.

While Spring and Summer are not optimal for those bands, I am seeing FST4W-120, -300 -900 and -1800 spots in Europe and on the East Coast.

On 2200M AI6VN/KH6 in Maui, N6GN in Colorado, and WA2TP in New York are decoding all the FST4W modes.

I expect that soon many the 50+ top spotting stations will be running Wsprdaemon Version 3.0 and extend FST4W listening coverage worldwide.

Hopefully that many FST4W listeners will encourage 2200/630/160 beacons to start transmitting in those modes

The Pi4 has just enough CPU to decode all 15 WSPR (i.e. 22M) bands and all of the FST4W modes on 2200/630/160M.

'git checkout 3.0.2' will get you the latest build (currently 3.0.2.4)
It is compatible with your existing config files, but to decode FST4W modes you will need to add specifications for them to your schedule.



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


Re: FST4W and 22M now working in version 3.0.2

Rob Robinett
 

I know that in the recent past Jim WA2ZKD has installed WD on his odroid systems.
WD 3.0 includes the option for you to configure it to give me remote access if you need installation help.

On Fri, May 20, 2022 at 3:45 AM <gerhard@...> wrote:

Hello Rob,

great news! I am running the monitor at OE3XOE, at the moment using DigiSkimmer for WSPR and FT8. I will try V3, but I would like to use a Odroid XU4 instead a RPI4. Do you have instructions to install on this hardware?

73 de Gerhard OE3GBB

 


Am 20.05.2022 06:53, schrieb Rob Robinett:

The new Wsprdaemon version 3.0 software running on 20 sites from Maui to Europe is configured to simultaneously decode and report to wsprnet.org WSPR-2 and all of the FST4W-xxx modes on 630M and 160M. i.e. only one Kiwi rx channel is needed to decode all of the modes in every WSPR cycle.

While Spring and Summer are not optimal for those bands, I am seeing FST4W-120, -300 -900 and -1800 spots in Europe and on the East Coast.

On 2200M AI6VN/KH6 in Maui, N6GN in Colorado, and WA2TP in New York are decoding all the FST4W modes.

I expect that soon many the 50+ top spotting stations will be running Wsprdaemon Version 3.0 and extend FST4W listening coverage worldwide.

Hopefully that many FST4W listeners will encourage 2200/630/160 beacons to start transmitting in those modes

The Pi4 has just enough CPU to decode all 15 WSPR (i.e. 22M) bands and all of the FST4W modes on 2200/630/160M.

'git checkout 3.0.2' will get you the latest build (currently 3.0.2.4)
It is compatible with your existing config files, but to decode FST4W modes you will need to add specifications for them to your schedule.



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


Re: FST4W and 22M now working in version 3.0.2

@OE3GBB
 

Hello Rob,

great news! I am running the monitor at OE3XOE, at the moment using DigiSkimmer for WSPR and FT8. I will try V3, but I would like to use a Odroid XU4 instead a RPI4. Do you have instructions to install on this hardware?

73 de Gerhard OE3GBB

 


Am 20.05.2022 06:53, schrieb Rob Robinett:

The new Wsprdaemon version 3.0 software running on 20 sites from Maui to Europe is configured to simultaneously decode and report to wsprnet.org WSPR-2 and all of the FST4W-xxx modes on 630M and 160M. i.e. only one Kiwi rx channel is needed to decode all of the modes in every WSPR cycle.

While Spring and Summer are not optimal for those bands, I am seeing FST4W-120, -300 -900 and -1800 spots in Europe and on the East Coast.

On 2200M AI6VN/KH6 in Maui, N6GN in Colorado, and WA2TP in New York are decoding all the FST4W modes.

I expect that soon many the 50+ top spotting stations will be running Wsprdaemon Version 3.0 and extend FST4W listening coverage worldwide.

Hopefully that many FST4W listeners will encourage 2200/630/160 beacons to start transmitting in those modes

The Pi4 has just enough CPU to decode all 15 WSPR (i.e. 22M) bands and all of the FST4W modes on 2200/630/160M.

'git checkout 3.0.2' will get you the latest build (currently 3.0.2.4)
It is compatible with your existing config files, but to decode FST4W modes you will need to add specifications for them to your schedule.


Re: Increased cpu load on v3

Rob Robinett
 

Hi Bryan,

In the latest 3.0.2 I have disabled some excessive internal validation code which might have contributed to the additional CPU load.

But 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.

As an alternative, we have tested the 64 bit Ubuntu 20.04 LTE for the Pi which includes Bash 5.1.16 which has fixed that memory leak. 

WA2TP has been running a WD 3.0.2 14 channel bullseye Pi4 but has to restart it daily of it runs out of memory.  He will be converting it to Ubuntu and my experience with it suggests he won't need the restarts.

Rob


FST4W and 22M now working in version 3.0.2

Rob Robinett
 

The new Wsprdaemon version 3.0 software running on 20 sites from Maui to Europe is configured to simultaneously decode and report to wsprnet.org WSPR-2 and all of the FST4W-xxx modes on 630M and 160M. i.e. only one Kiwi rx channel is needed to decode all of the modes in every WSPR cycle.

While Spring and Summer are not optimal for those bands, I am seeing FST4W-120, -300 -900 and -1800 spots in Europe and on the East Coast.

On 2200M AI6VN/KH6 in Maui, N6GN in Colorado, and WA2TP in New York are decoding all the FST4W modes.

I expect that soon many the 50+ top spotting stations will be running Wsprdaemon Version 3.0 and extend FST4W listening coverage worldwide.

Hopefully that many FST4W listeners will encourage 2200/630/160 beacons to start transmitting in those modes

The Pi4 has just enough CPU to decode all 15 WSPR (i.e. 22M) bands and all of the FST4W modes on 2200/630/160M.

'git checkout 3.0.2' will get you the latest build (currently 3.0.2.4)
It is compatible with your existing config files, but to decode FST4W modes you will need to add specifications for them to your schedule.


Re: Increased cpu load on v3

Bryan Klofas
 

Hey Rob--

Interesting, thanks for the background on the changes. I didn't realize that FST4W was added, I just kept the same wsprdaemon.conf file as 2.8 so I didn't see the new text. I can write something about this for the README.md if that helps?

Are the FST4W frequencies the same as WSPR? I only have one KiwiSDR with a loop antenna, and would like to receive as many WSPR bands as possible. If it takes away a WSPR band, should I even bother with FST4W?

I will keep dropping the '-o' level top keep the Pi happy. Not the greatest, but that's all I have.

Thanks, have a great evening!
--
Bryan Klofas

On 5/15/22 10:56, Rob Robinett wrote:
Because may wav file recording errors were not detected in 2.x, in 3.0 I added many checks of the wav file which may account for some of the increased CPU utilization.  In addition, in order to support FST4W decoding, in 3.0 wav files are each 1 minute long and are assembled into 2/5/15/30 long wav files as required by the decoding modes.  Doing that incurs both CPU and memory space costs.  For configurations which decode only WSPR-2, I think most sites can continue to decode 14 bands on a Pi4, although at KPH I found the Pi4 was occasionally running out of CPU time and thus I reduced the intensity of the 'wsprd' efforts by adding the line:
WSPRD_CMD_FLAGS="-C 500 -o 3 -d"
to the config file.
At WA2TP which is much closer to the East Coast and European beacons I needed to reduce it even further to '-o 2' with:
WSPRD_CMD_FLAGS="-C 500 -o 2 -d"
However I think even '-o 2' incurs only a small penalty on decode sensitivity, since that Pi fed by one dipole and logging as 'WA2TP-1' is #11 worldwide and not far below the #6 WW 'WA2TP' which is fed by 5 antennas all decoding at '-o 4'
Reducing the '-o' level will not help FST4W decoding, so many of the top spotting sites already have moved to using i5, li7 or i9 WD servers. Doing so will allow them to decode FST4W beacons and I hope will encourage more LF/MF/160M sites to migrate to that mode since their transmissions will get many more reports.


Re: Increased cpu load on v3

Rob Robinett
 

Because may wav file recording errors were not detected in 2.x, in 3.0 I added many checks of the wav file which may account for some of the increased CPU utilization.  In addition, in order to support FST4W decoding, in 3.0 wav files are each 1 minute long and are assembled into 2/5/15/30 long wav files as required by the decoding modes.  Doing that incurs both CPU and memory space costs.  For configurations which decode only WSPR-2, I think most sites can continue to decode 14 bands on a Pi4, although at KPH I found the Pi4 was occasionally running out of CPU time and thus I reduced the intensity of the 'wsprd' efforts by adding the line:

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

to the config file. 
At WA2TP which is much closer to the East Coast and European beacons I needed to reduce it even further to '-o 2' with:

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

However I think even '-o 2' incurs only a small penalty on decode sensitivity, since that Pi fed by one dipole and logging as 'WA2TP-1' is #11 worldwide and not far below the #6 WW 'WA2TP' which is fed by 5 antennas all decoding at '-o 4'

Reducing the '-o' level will not help FST4W decoding, so many of the top spotting sites already have moved to using i5, li7 or i9 WD servers.  Doing so will allow them to decode FST4W beacons and I hope will encourage more LF/MF/160M sites to migrate to that mode since their transmissions will get many more reports.


Re: Increased cpu load on v3

Rob Robinett
 

While in 'top' type the letter 'c' to have it display the full command lines.
Then type 'W'  to have 'top' save that as its default display mode.
There is a bug in the Bash 5.1.4 included in both 32bit and 64 bit 'bullseye which will eventually cause WD to consume all of the memory space.
Until there is a fixed version of bash available, you may need to restart WD every day or week to avoid a locked up Pi.

On Sun, May 15, 2022 at 1:09 AM Erwin - PE3ES - F4VTQ via groups.io <waterwin2=yahoo.com@groups.io> wrote:
I looked at my 64 bit Pi and see this. The pi has a very small fan in a ice-cube tower of 4 and is in a room at 25 C. Quite normal temp for the Pi doing this work



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


Re: Increased cpu load on v3

Erwin - PE3ES - F4VTQ
 
Edited

I looked at my 64 bit Pi 4 B and see this. The pi has a very small fan in a ice-cube tower of 4 and is in a room at 25 C. Quite normal temp for the Pi doing this work


Increased cpu load on v3

Bryan Klofas
 

Hello Rob--

I've been playing around with v3 recently, and it seems to work much better than v2.8. I like the increased debugging when shutting down, and it's gotta be easier to maintain.

But, anecdotally, the new version consumes much more system resources than v2.8. My computer is a Pi 3B, 64-bit bullseye, decoding 7 bands from an up-to-date local Buster KiwiSDR. I know I need a better processor, but this is going to a remote site and it's all I have for now.

Using v2.8, 15-minute load is around 2.5. At the 2-min mark, the load shoots up to 4 when wsprd is running, normal. Additionally, the CPU temp is always in the mid 60's deg C.

Using v3.0.2, 15-minute load is 4+. At the 2-min mark, load is 5+ for the wsprd decoding period. Processor temp is 70+ degrees C.

I'm scratching my head as to why this could be. Same Pi 3B hardware, same OS, during the same time frame/band conditions. The only Apt package differences I can tell between v3 and v2.8 is python3-matplotlib and python3-scipy; I'm assuming that v3 uses the pip packages of these two, vs apt packages for v2.8.

I ran these tests with a wsprd decoding depth of 3 (from standard 4), because "-o 4" wsprd periods were too long, and the CPU temp was above 80 deg C and throttling.

Have you seen this problem in your testing? I guess the ultimate answer is "throw a better computer at it".
--
Bryan Klofas KF6ZEO


wsprnet.org down due to power outage CET 23:30 - 13-5-2022

Erwin - PE3ES - F4VTQ
 
Edited

Yes it is Friday the 13th.
Owner is doing his utmost to resolve.
Hope for better news tomorrow morning.

Fingers crossed.
Good night from France.

801 - 820 of 1670