rrobinet

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

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

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