rrobinet

Hi Steve,

I am adding support for all the FST4W-nnn modes to wsprdaemon V3.0.

The auto-wspr feature built in to the Kiwi is a port from an earlier version of WDSJT-x and required a significant amount of code rewriting. Also, that current autowspr feature is severely constrained by the limited CPU power of the BeagleBone.

It was at John's suggestion that I started the wsprdaemon project which moves all of the WSPR signal processing to a remote server which can run the latest releases of WSJT-x and have as much CPU power as is required to execute the new WSPR modes.

Rob

Thanks to John's help I was able to successfully upgrade 6 Kiwis to Debian 11 / v 1.701. No Kiwi FPGAs were damaged by the 12V DC, but it took me some experimentation to find a reliable OS upgrade process:

1) Remove the KiwiPCB to gain easy access to the boot button, insert the microSD, and apply power to the BBG through the microUSB port.

2) After the BBG completed its copy from microSD and turned itself off, remove the microUSB power cable. Carefully re-attach the KiwiPCB to the BBG, attach an ethernet cable, and power up from 5V to the barrel connector.

3) After several minutes I open the Kiwi's /admin page and look at the Console->monitor build progress page to see if the Kiwi software upgrade was in progress. If so, leave the Kiwi powered on and undisturbed for the hour or so it takes to complete an update to 701. If there is no evidence the Kiwi is executing an auto-update, then execute a manual update and monitor its progress from the Console->monitor build progress page

After the update to v1.701 is complete, I change the default admin settings for:

a) GPS: QZSS:off, Acquire if Kiwi busy:on (very important, I think), Set date from GPS:on

b) Update: Automatically install software updates:No. (This defaults to Yes and after some microSD installs the Kiwi started upgrading automatically. When I found the Kiwi unresponsive I power cycled the Kiwi in the midst of the upgrade and I ended up with a Kiwi with corrupted installation)

I have a dozen more Kiwis which need OS upgrades and I now am confident I can do that reliably.

Hi Martin,

Your test page is the best discussion of receive site power supply issues I have ever found. Could you post it somewhere that I could refer to on my wsprdaemon.org site?

As you have shown and Glen N6GN has taught me, many receive site RFI problems come from common mode currents flowing through the milli-ohms of Kiwi PCB ground plane resistence. The PSU is frequently the major, but not the only, source of those currents.

Many additional currents flow when there is an antenna lead connected to the Kiwi's RF input SMA. It is of course important to minimize the PSU as a source of ground loop currents, but in a working receive site the antenna + LNA (with its own PSU) + feed line almost always introduces one or more ground loops which are additional sources of ground loop RFI currents.

At my KPH, KFS and AI6VN/KH6 sites where the PSU ground currents are well suppressed, I have still needed the 30+ dB of common mode noise suppression provided by the MiniCircuits T1-1 isolation transformer: https://www.minicircuits.com/WebStore/dashboard.html?model=T1-1-KK81%2B

Every site differs, so the T1-1 may be of no help but it has been an essential component at my sites. Adding a LNA at or near the antenna feed point can with care also improve the signal levels while not adding to the ground currents.

My sites are powered by 12VDC battery backup systems fed by a 20A linear regulator and I have found these $1.25 3A switching supplies to be very useful to convert that 12V to the 5V needed by the Kiwis. These supplies ramp up quickly enough to match the Kiwi's power-up requirement, and they switch at 925 KHz so the fundamental RFI and the first few harmonics are outside HAM bands, spaced by almost 1 MHz, and the common mode currents can be well suppressed by small torroids on the input and output leads

To see the spectrum of a Kiwi system using those components, open: http://www.kphsdr.com:8073/

73,

Rob

It will support both modes and all the packet lengths

When I connect the microUSB port of the the Kiwi to a USB port of a Raspberry Pi, the Pi sees a new ethernet interface appear on LAN 192.168.7.0/30. The Kiwi assigns itself 192.168.7.2, but I forget if it acts as a DHCP server to the Pi. So on the Pi you may need to assign that new USB 'dongle' the address 192.168.7.1.

After that the Kiwi UI can be accessed at 192.168.7.2

The Park Service has denied us volunteers access to the KPH facility since the start of Covid last spring. While that is annoying I am sympathetic to their situation. If they were to grant exceptions to one set of citizens, then other would want the same privileges.

As soon as I am allowed, I will go out there and restore operation. Look for KPH WSPR spots on http://jimlill.com/today_int.html to learn when that happens

Thanks Yuri,

I was not aware of frp.

I'll make it a configurable option in a future version of wsprdaemon.

Rob

SOLVED

I carefully read the "Using a USB network connection for initial Beagle access" section of the user manual but could access the Kiwi from a Win10 PC or from a Raspberry Pi

On the Kiwi, 'ifconfig' command lists usb0 with IP address 192.168.7.2 and MAC 40:bd:32:e5:40:02, and usb1 with IP 192.168.6.2 and MAC 1c:ba:8c:a2:ed:73

On the PC, when I plug in the USB cable from the Kiwi, a new DHCP network interface appears but that interface gets no IP address. The beaglebone documentation describes a drive which should appear as well, but Win 10 shows only this additional network interface with MAC 40:bd:32:e5:40:01. That MAC differs by 1 from the usb0 MAC on the Kiwi, so the PC and Kiwi are communicating.

On the Pi, when I plug in the USB cable from the Kiwi two new interfaces appear: eth2 with the same MAC 40:bd:32:e5:40:01 which is assigned to the PC interface, and eth1 with MAC 1c:ba:8c:a2:ed:72, but those Pi interfaces give themselves self-assigned IP address. Running 'tcpdump -i eth1' on the Pi I can see it sending out DHCP request packets but getting no response, so I infer that the BeagleBone is not responding to DHCP on those usb0/1 ports.

However, by configuring the Pi's eth1 and eth2 with static addresses I was able to gain complete ssh and GUI access to the Kiwi at both 192.168.6.2 and 192.168.7.2.

To manually configure those IP address on a Pi, add these four lines to /etc/dhcpcd.conf

pi@Berk-Pi4b-90:~ $ tail -4 /etc/dhcpcd.conf interface eth1 static ip_address=192.168.6.1/30 interface eth2 static ip_address=192.168.7.1/30 pi@Berk-Pi4b-90:~ $

I don't have a second Kiwi here to test a two Kiwi system, but it seems I could modify the usb0 address 192.168.7.2 in /etc/network/interfaces to 192.168.8.2 and configure the Pi to add a corresponding ethX with 192.168.8.1

SOLVED

I carefully read the "Using a USB network connection for initial Beagle access" section of the user manual but could access the Kiwi from a Win10 PC or from a Raspberry Pi

On the Kiwi, 'ifconfig' command lists usb0 with IP address 192.168.7.2 and MAC 40:bd:32:e5:40:02, and usb1 with IP 192.168.6.2 and MAC 1c:ba:8c:a2:ed:73

On the PC, when I plug in the USB cable from the Kiwi, a new DHCP network interface appears but that interface gets no IP address. The beaglebone documentation describes a drive which should appear as well, but Win 10 shows only this additional network interface with MAC 40:bd:32:e5:40:01. That MAC differs by 1 from the usb0 MAC on the Kiwi, so the PC and Kiwi are communicating.

On the Pi, when I plug in the USB cable from the Kiwi two new interfaces appear: eth2 with the same MAC 40:bd:32:e5:40:01 which is assigned to the PC interface, and eth1 with MAC 1c:ba:8c:a2:ed:72, but those Pi interfaces give themselves self-assigned IP address. Running 'tcpdump -i eth1' on the Pi I can see it sending out DHCP request packets but getting no response, so I infer that the BeagleBone is not responding to DHCP on those usb0/1 ports.

However, by configuring the Pi's eth1 and eth2 with static addresses I was able to gain complete ssh and GUI access to the Kiwi at both 192.168.6.2 and 192.168.7.2.

To manually configure those IP address on a Pi, add these four lines to /etc/dhcpcd.conf

pi@Berk-Pi4b-90:~ $ tail -4 /etc/dhcpcd.conf interface eth1 static ip_address=192.168.6.1/30 interface eth2 static ip_address=192.168.7.1/30 pi@Berk-Pi4b-90:~ $

I don't have a second Kiwi here to test a two Kiwi system, but it seems I could modify the usb0 address 192.168.7.2 in /etc/network/interfaces to 192.168.8.2 and configure the Pi to add a corresponding ethX with 192.168.8.1

I could imagine installing WD on a BBAI machine and dedicate a core to run it.
But synchronizing Kiwi and WD code upgrades would be a mess.
For example, just this week I was able to upgrade 20+ WD sites to use the wsprd in WSJT-x 2.2.1 which produces up to 6% more spots from the same antenna+Kiwi.
Also, many installations use 2 or more antenna+Kiwis, and embedding WD in one Kiwi would result in an asymmetric set of Kiwis.

So it is far better to run WD on a $35 Pi 3b (or better yet a 2/4Gb Pi 4) which can support 30+ channels of Kiwi bands.