Closed Claudio-Sjo closed 1 year ago
Like all direct conversion SDRs, the Kiwi's ADC is presented by all signals delivered by the the antenna system. So the strong signal tolerance of the Kiwi is limited to the instantaneous sum of all those signals at the input of the ADC which overloads at abut -14 dBm. The tuning and filtering is performed entirely in FPGA firmware and software , so as long as the Kiwi's red OV signal is not flashing next to the S-meter, there are none of the strong signal overload problems seen in legacy heterodyne receivers.
In addition, the 'wsprd' decode program from WSJT-x which is used by WD to decode signals expects a wav file with audio in the range of 1340-1660 Hz or wsprd will produce erroneous SNR values. So WD run this kwirecorder command:
pi@KPH-Pi4b-85:/home/wsprdaemon/wsprdaemon $ ps aux | grep kiwirec | head -1 pi 13078 2.1 0.5 45732 21224 ? S<l Jun19 22:45 python3 -u /home/pi/wsprdaemon/kiwiclient/kiwirecorder.py --freq=1836.6 --server-host=10.14.70.76 --server-port=8073 --OV --user=wsprdaemon_v3.0.3 --password=mrhsisok --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1340 --hp-cutoff=1660 --dt-sec=60 pi@KPH-Pi4b-85:~/wsprdaemon $
Overloading of the Kiwis has become a problem in recent months as the increase in sunspots has made broadcast signals in the 41M and higher SW broadcast bands much stronger. At KPH I had to reduce the LNA gain ahead of the 20-10M Kiwi by 10 dB to keep it from being overloaded very frequently. Like most sites, KPH uses 550-1600 Hz AM band blocking filters which now may need to supplemented with 41M and other SW broadcast band blocking filters. The need for those filters is not limited to Kiwis; SDRPlays, AirSpys and other SDRs can also benefit from the use of such filters.
To help users understand the extent of their overloads, in WD 3.0 I have added the 'show-ovs' command:
pi@KPH-Pi4b-85:/home/wsprdaemon/wsprdaemon $ show-ovs KPH_HF_77 22: Tue 07 Jun 2022 12:44:09 UTC: kiwirecorder_manager_daemon() Found 2577 new - 2554 old = 23 new OV events were reported by kiwirecorder.py KPH_HF_77 10: Tue 07 Jun 2022 12:44:06 UTC: kiwirecorder_manager_daemon() Found 2625 new - 2605 old = 20 new OV events were reported by kiwirecorder.py KPH_HF_77 12: Fri 10 Jun 2022 02:02:07 UTC: kiwirecorder_manager_daemon() Found 3447 new - 3424 old = 23 new OV events were reported by kiwirecorder.py KPH_HF_77 15: Fri 10 Jun 2022 02:02:17 UTC: kiwirecorder_manager_daemon() Found 3487 new - 3463 old = 24 new OV events were reported by kiwirecorder.py KPH_HF_77 17: Tue 07 Jun 2022 12:44:10 UTC: kiwirecorder_manager_daemon() Found 2645 new - 2623 old = 22 new OV events were reported by kiwirecorder.py KPH_HF_77 20: Tue 07 Jun 2022 12:44:09 UTC: kiwirecorder_manager_daemon() Found 2583 new - 2562 old = 21 new OV events were reported by kiwirecorder.py KPH_HF_76 160: Tue 07 Jun 2022 12:44:09 UTC: kiwirecorder_manager_daemon() Found 2929 new - 2902 old = 27 new OV events were reported by kiwirecorder.py KPH_HF_76 30: Fri 10 Jun 2022 02:02:18 UTC: kiwirecorder_manager_daemon() Found 2437 new - 2415 old = 22 new OV events were reported by kiwirecorder.py KPH_HF_76 40: Fri 10 Jun 2022 02:02:17 UTC: kiwirecorder_manager_daemon() Found 3902 new - 3875 old = 27 new OV events were reported by kiwirecorder.py KPH_HF_76 80eu: Fri 10 Jun 2022 02:02:19 UTC: kiwirecorder_manager_daemon() Found 3288 new - 3260 old = 28 new OV events were reported by kiwirecorder.py KPH_HF_76 80: Fri 10 Jun 2022 02:02:08 UTC: kiwirecorder_manager_daemon() Found 3881 new - 3857 old = 24 new OV events were reported by kiwirecorder.py pi@KPH-Pi4b-85:~/wsprdaemon $
I may be wrong pointing at wsprdaemon, I assumed that the plugin for WSPR in kiwiradio is wsprdaemon, meaning that when accessing kiwiradio from the web and opening WSPR plugin I am running wsprdaemon. If this is not the case, please apologize me. Otherwise "--lp-cutoff=1340 --hp-cutoff=1660" doesn't work as setting the bandwidth manually in kiwiradio makes WSPR decoding work.
The WSPR extension built into the Kiwi is a great learning tool, but it suffers from being a port of the very old WSJT-x 1.3 wspr decoder algorithm. For sites with good antenna and RF distribution systems, an even more serious limitation of the Kiwi's extension is that there is not enough free CPU power in the Kiwi's CPU to decode a fraction of the spots in a busy band. WD 3.0 also adds support for decoding the new FST4W modes.
On Tue, Jun 21, 2022 at 12:39 AM Claudio-Sjo @.***> wrote:
I may be wrong pointing at wsprdaemon, I assumed that the plugin for WSPR in kiwiradio is wsprdaemon, meaning that when accessing kiwiradio from the web and opening WSPR plugin I am running wsprdaemon. If this is not the case, please apologize me. Otherwise "--lp-cutoff=1340 --hp-cutoff=1660" doesn't work as setting the bandwidth manually in kiwiradio makes WSPR decoding work.
— Reply to this email directly, view it on GitHub https://github.com/rrobinett/wsprdaemon/issues/20#issuecomment-1161374929, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIFAQZEPLOKHREYS4GQVYHLVQFWRHANCNFSM5ZJYFTXQ . You are receiving this because you commented.Message ID: @.***>
-- Rob Robinett AI6VN @.*** mobile: +1 650 218 8896
While exploiting wsprdaemon in kiwiradio, the bandwith cannot be set as kiwiradio is configured as USB and the whole USB bandwidth is used to feed wspr. Kiwiradio bandwidth should be set +/- 100Hz from the central frequency of the wished bandwidth, this avoids that strong signals in the nearby make wsprdeamon blind.