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
  • V 1.214 WSPR-autorun on 8 channels not so effective as on 4 channels [known limitation]

    You can work around the Kiwi's autowspr CPU limits in both 4 and 8 channel mode by running on a Pi the kiwiwspr.sh script I have just published to the "Problems Solved' forum. I have tested the script on a Pi and it can capture 20+ streams from 3 Kiwis at once and decode and post them using the WSJT-x 1.9.1 'wsprd' application.
    WA2ZKD
  • 8 channel Kiwi WSPR decoding script 'kiwiwspr.sh' using Raspberry Pi or other external server

    The Kiwi's WSPR extension is a marvel and provides a much better view of the WSPR band operation than does WSJT-x.
    However the Kiwi is not quite as good as WSJT-x at decoding spots on crowded and/or noisy bands with many low level signals.
    The attached script addresses many of the Kiwi's limitations as a WSPR decoder by moving the WSPR signal processing to an external server.
    For example, at KPH (http://kphsdr.com/) this script has been simultaneously and reliably decoding 14 WSPR bands from two Kiwis on one Raspberry Pi 3b (not even a 3b+) for several months.
    Once installed on the Pi (or other Linux computer) the script runs automatically in the background after power up or reboot.

    The benefits over using the Kiwi's internal autowspr decoder extension are:

    1) You can decode 8 WSPR bands at once on one Kiwi. The Kiwi can be configured to autowspr 8 bands but its CPU is severely overtaxed and thus very few spots get decoded in that mode.
    2) On busy bands even in 4 channel mode the Kiwi CPU runs out of time, in which case kiwiwspr.sh will decode 1.5-3x the number of spots
    3) I believe that the Kiwi's autowspr decoder is derived from an older version of 'wsprd', so even on quiet bands kiwiwspr will extract 20% more spots than autowspr
    4) My script decodes using the recent 'wsprd' decoder included in the WSJT-x 1.9.1 package and can easily be upgraded to any newer version of 'wsprd'
    5) kiwiwspr.sh supports scheduled band changes, so you can spot on 630 and 160M at night and switch those channels to 15M and 10M during the day
    Times can be specified as HH:MM or 'sunrise/sunset +- HH::MM'

    I have tried to make installation self documenting after you copy it into a directory on your Pi, make it executable (chmod +x kiwiwspr.sh), and execute './kiwiwspr.sh'.
    Of course I will be happy to help with installation and debug and am soliciting more beta testers who will inevitably uncover bugs and feature improvements.

    Since installing this script KPH has become one of the top spotters in the world and second only to K9AN (with his more favorable central USA QTH) in North America. My hope is that more Kiwi owners will join KPH at the top of the lists.

    Many thanks go to John Seamons who provided the extensions to his kiwirecorder.py script upon which kiwiwspr.sh is built.
    WA2ZKD
  • use of kiwirecorder, kiwiwspr etc

    I have just finished version 0.5d which adds support for a watchdog and scheduled band configuration changes.
    It also incorporates many command line changes which I hope make it easier to use.
    However it requires changes to the CAPTURE_JOBS[] array in the kwiconfig.conf file and you must add at least one WSPR_SCHEDULE[] entry.
    It is running well at 3 sites, but as always save your current kwiwspr.sh and kwiwspr.conf file in case this new version doesn't work for you.
    It is a very lightweight program and you can easily spot all 14 LF/MF/HF WSPR bands on a Raspberry Pi
    I welcome comments and bug reports
    G0LUJWA2ZKDGene
  • use of kiwirecorder, kiwiwspr etc

    I have just finished version 0.5d which adds support for a watchdog and scheduled band configuration changes.
    It also incorporates many command line changes which I hope make it easier to use.
    However it requires changes to the CAPTURE_JOBS[] array in the kwiconfig.conf file and you must add at least one WSPR_SCHEDULE[] entry.
    It is running well at 3 sites, but as always save your current kwiwspr.sh and kwiwspr.conf file in case this new version doesn't work for you.
    It is a very lightweight program and you can easily spot all 14 LF/MF/HF WSPR bands on a Raspberry Pi
    I welcome comments and bug reports
    G0LUJWA2ZKDGene
  • use of kiwirecorder, kiwiwspr etc

    I have just finished version 0.5d which adds support for a watchdog and scheduled band configuration changes.
    It also incorporates many command line changes which I hope make it easier to use.
    However it requires changes to the CAPTURE_JOBS[] array in the kwiconfig.conf file and you must add at least one WSPR_SCHEDULE[] entry.
    It is running well at 3 sites, but as always save your current kwiwspr.sh and kwiwspr.conf file in case this new version doesn't work for you.
    It is a very lightweight program and you can easily spot all 14 LF/MF/HF WSPR bands on a Raspberry Pi
    I welcome comments and bug reports
    G0LUJWA2ZKDGene
  • use of kiwirecorder, kiwiwspr etc

    I have implemented version 0.5c of kiwiwspr.sh which includes a watchdog daemon that checks the status of the kiwirecorder.py sessions each odd 2 minutes and restarts or performs scheduled configuration changes on them as needed. The watchdog log shows that one or more (and sometimes all) of them dead at random times. I will need to modify kiwiwspr.sh to save the error output of kiwirecorder.py, but looking at the restart times strongly suggests those restarts are happening at semi-random times. So they are unlikely generated by your update check. I'm sorry if I mislead you into a unneeded diagnostic task.
    WA2ZKD
  • use of kiwirecorder, kiwiwspr etc

    The Kiwi runs an update task once a day to check for a new SW version and as part of that process terminates autowspr and kiwirecorder.py sessions for reasons only known to John. So that is one more reason for the need for a watchdog. My enhanced version with scheduled band changes is almost ready for testing
    WA2ZKDPowernumptyG0LUJ
  • use of kiwirecorder, kiwiwspr etc

    The Kiwi runs an update task once a day to check for a new SW version and as part of that process terminates autowspr and kiwirecorder.py sessions for reasons only known to John. So that is one more reason for the need for a watchdog. My enhanced version with scheduled band changes is almost ready for testing
    WA2ZKDPowernumptyG0LUJ
  • use of kiwirecorder, kiwiwspr etc

    The Kiwi runs an update task once a day to check for a new SW version and as part of that process terminates autowspr and kiwirecorder.py sessions for reasons only known to John. So that is one more reason for the need for a watchdog. My enhanced version with scheduled band changes is almost ready for testing
    WA2ZKDPowernumptyG0LUJ
  • What is the status of the WSPR background and autostart features? [added in v1.181]

    I didn't know there was any activity on 60M, but of course I'll add it.
    I too want to mmimic the "band Hopping' feature of WSJT-x. I won't have time to work on it for a few days.
    In the mean time, you could create a set of kiwiwspr.conf files and have the cron job run "-J z; mv replace kiwiwspr.conf; -J a"
    WA2ZKD