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

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.

V2.9 had a bug which blocked generating noise level graphs. That has been fixed in 2.9a and you can learn more at: http://wsprdaemon.org/forum.html

The new code is backwards compatible with earlier WD.conf and running installations.

WD extended spots are stored in a new TS table 'wsprdaemon_spots' on wsprdaemon.org and include high resolution frequency and DT spot values and include all the fields reported by 'wsprd' in ALL_WSPR.TXT.

The noise values now stored in 'wsprdaemon_noise' and now include a count of overload events reported by the Kiwi during the 2 minute long WSPR cycle.

I will be posting to http://wsprdaemon.org/forum.html about features and fixed to V2.9