-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrong bandwidth in kiwiradio #20
Comments
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 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 |
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. |
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
<#20 (comment)>,
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.
The text was updated successfully, but these errors were encountered: