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,300
Last Active
Roles
Member
Points
9
  • What is the status of the WSPR background and autostart features? [added in v1.181]

    I am currently running 6 instances of this command line script on a Raspberry Pi 3b+ at KPH, and it should also run on Max OSX.

    To use it:

    1) create a directory for it (e.g. /home/pi/kiwiwspr) and copy the attached kiwiwspr.sh into that directory
    2) execute: "chmod +x kiwiwspr.sh"
    3) execute ./kiwiwspr.sh -h

    The program will guide you through the setup of the environment. It depends upon:

    1) the 'bc' (Binary Calculator)
    2) the kiwirecorder.py program
    3) and WSJT-x. WSJT-x doesn't need to run, only the 'wsprd' command line application is used here.
    4) Then you will need to edit the template configuration file 'kiwiwspr.conf' file created by kiwiwspr.sh to include the IP address(es) of your Kiwi(s)
    5) The simplest way to run the program is to execute './kiwiwspr.sh -J a' (start all jobs)
    ./kiwiwspr.sh -j will display the status of all the jobs defined in kiwiwspr.conf
    ./kiwiwspr.sh -h attempts to describe all of the command line options, although I hope you will need to use only "-J a" an "-J z"

    There are log files for each job in the /tmp/kiwi-captures/... directory tree if you want to look 'under the hood'

    I expect that you will experience problems installing and running ?this problem, so don't hesitate to ask for help.
    WA2ZKD
  • 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.
    KA7ULX1DQ
  • 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.
    KA7ULX1DQ
  • WSPR without browser

    I could also use this feature in some form.  I have been running four WSPR sessions on my home PC, but the waterfall display brings my VPN connection to my MAC desktop to a halt.  So when my Mac rebooted itself, I cannot restart any sessions through a MAC Screen session connecting to my home desktop
    WA2ZKD