The KiwiSDR 2 online store is open for orders! Please visit kiwisdr.nz
Please visit kiwisdr.com (documentation) and kiwisdr.nz (online store)
rrobinet
I have configured several Kiwis for wifi access by attaching an inexpensive router configured as a Wifi client to the ethernet port of the Kiwi. This $25 TP Link has worked well for me:
https://smile.amazon.com/TP-Link-Wireless-Portable-Travel-Router/dp/B00TQEX8BO/ref=sr_1_14?keywords=tplink+wifi+router&qid=1548188019&sr=8-14
In principle one could enable the internal BB Wifi or attach a USB wifi adapter, but I am reluctant to fiddle with the Kiwi's OS.
About
- Username
- rrobinet
- Joined
- Visits
- 1,266
- Last Active
- Roles
- Member
- Points
- 8
-
The auto-wspr extension misses signals on a busy band
Here are the results of some further auto-wspr testing. My conclusion is that auto-wspr works well as long as you are not flooded with 20+ signals.
I have previously found that at KPH on 20M the Kiwi auto-wspr daemon runs out of CPU time in many 2 minute spot times before it can decode all of the spots. I'm not sure which version of the WSPR decoder SW is in the current Kiwi v1.195 SW, but I don't expect that the decode SW will be optimized for CPU performance anytime soon. ?
So at KPH I have turned of Kiwi 20M auto-wspr and been feeding Kiwi 20M audio to WSJT-x running on the Mac Air in the KPH rack. Since yesterday all of the KPH 20M spots have been recorded by that setup. Hopefully it will be a stable configuration, and I suspect I'll need to implement the same signal flow on 40M, 30M and perhaps other high WSPR traffic HF bands.
However I wondered if auto-wspr could be useful on bands with much less traffic. So last night I set up an audio feed from KPH to WSJT-x running on my Berkeley Mac which spotted as 'KPH/B'. That test showed some relatively small differences between the two spotters. Of the 293 unique spots logged by one or both of the systems, there were 59 spots which were only logged by one system, Of those 59 spots, 29 were unique to the auto-spotter and 32 were unique to WSJT-x.
Unfortunately I can't get a clean version of the comparison into this post
These results suggest to me that auto-wspr can be used on many bands at KPH. As we get more Kiwis at KPH I'll repeat this test on each band If I see little difference I'll use auto-wspr. I found this to be an encouraging result. -
The auto-wspr extension misses signals on a busy band
Here are the results of some further auto-wspr testing. My conclusion is that auto-wspr works well as long as you are not flooded with 20+ signals.
I have previously found that at KPH on 20M the Kiwi auto-wspr daemon runs out of CPU time in many 2 minute spot times before it can decode all of the spots. I'm not sure which version of the WSPR decoder SW is in the current Kiwi v1.195 SW, but I don't expect that the decode SW will be optimized for CPU performance anytime soon. ?
So at KPH I have turned of Kiwi 20M auto-wspr and been feeding Kiwi 20M audio to WSJT-x running on the Mac Air in the KPH rack. Since yesterday all of the KPH 20M spots have been recorded by that setup. Hopefully it will be a stable configuration, and I suspect I'll need to implement the same signal flow on 40M, 30M and perhaps other high WSPR traffic HF bands.
However I wondered if auto-wspr could be useful on bands with much less traffic. So last night I set up an audio feed from KPH to WSJT-x running on my Berkeley Mac which spotted as 'KPH/B'. That test showed some relatively small differences between the two spotters. Of the 293 unique spots logged by one or both of the systems, there were 59 spots which were only logged by one system, Of those 59 spots, 29 were unique to the auto-spotter and 32 were unique to WSJT-x.
Unfortunately I can't get a clean version of the comparison into this post
These results suggest to me that auto-wspr can be used on many bands at KPH. As we get more Kiwis at KPH I'll repeat this test on each band If I see little difference I'll use auto-wspr. I found this to be an encouraging result. -
WSPR without browser