jks

GPS acquisition uses a large FFT that runs in an uninterruptible fashion since it is a library routine (i.e. the Kiwi task scheduling can't influence its execution). Early on there was a fear this might cause realtime issues (audio drops) under heavy loading (many connections, WSPR extension use).

Originally it seemed use of an individual Kiwi was pretty sparse and so it wouldn't hurt to pause the GPS acquisition process when there was more than one user connection. After all, if acquisition is off it takes quite a long time for all the currently tracked sats to move out-of-range such that there are no sats left. So this seemed an acceptable compromise. But many things have changed since then. Christoph figured out how to make the acquisition FFT a power-of-two which sped it up considerably. We now have applications that make full-time connections to all of the channels (wsprdaemon, kiwirecorder, WSPR extension autorun).

These days there doesn't seem to be any significant problems letting the GPS always acquire.

The Kiwi is starting to function using a BBAI in place of the BBG/BBB. Lots of issues still, but in principle it works.

Turns out the US $125 price from Mouser and others is $100 MSRP plus the current $25 US China tariff. So for example you can get it from UK Farnell for £80/$100 (but then +VAT if delivered in EU). Seeed's Shenzhen-based website sells it for $125 which I find both amusing and sad. The AI is built by Embest, a, you guessed it, Shenzhen company. Go figure.

The thing is a beast. If you don't use some significant forced-air cooling it goes into thermal shutdown pretty quickly. It will also shutdown when your power supply can't deliver enough current! (5V 3A max)

Compile times for Kiwi codebase: (clang compiler, "make -j n" used)

BBAI    Debian 9.11    1m50s (3x faster)    TI AM5729 ARM Cortex-A15, 2 cores, 1.5 GHz
BBB/G   Debian 8.5     6m10s                TI AM3359 ARM Cortex-A8,  1 core,  1.0 GHz

Well, I told you so.

Guess what I just discovered? For all of you who upgraded your Kiwis beyond the stock Debian 8.5, and then did backups to an sd card, all those backups are UNUSEABLE as a recovery re-flasher by ANY version of BeagleBone Debian. Those cards will not boot and re-flash your Kiwi like they're supposed to.

Kiwi release v1.334 fixes this issue provided you make new backups using v1.334 or any future release. Out of the 400+ public Kiwis 60 of them are running Debian 8.6+ So this is not a small problem. PLEASE wait for the update and make new backups!

What happened? Well, sometime after Debian 8.5 the mkfs.ext4 utility that creates "ext4" format filesystems used on sd cards and the Beagle on-board eMMC was changed to use 64-bit addressing to support huge filesystem sizes. That's fine. But the problem is that uBoot, the little program at the beginning of every bootable device, was not changed because that's not part of a Debian upgrade. That's a BeagleBone distro issue. All of this was discovered by the Beagle folks back in 2016. And Beagle distros that used Debian 8.6+ made sure to add an option to mkfs.ext4 preventing the use of 64-bit addressing as a workaround until uBoot eventually gets 64-bit support.

But just upgrading Debian alone beyond 8.5, without the benefit of the associated Beagle distro, doesn't get this workaround. I spent a long time trying to figure out why sd cards built with Debian 8.6+ wouldn't boot. They looked fine when inspected using Debian itself. It wasn't until I learned how to inspect an sd card filesystem from uBoot that I saw they were corrupted from uBoot's point of view.

Okay, there is a trial of this in today's v1.334, e.g. "kiwi:8073/users" Only responds to connections from the local network.
Response is JSON with a couple of the fields URI encoded. This mostly because it already existed as a protocol with the Kiwi Javascript and I've been trying to move everything to JSON anyway.

Example:

[{"i":0,"n":"ZL%2fKF6VO","g":"Tauranga,%20New%20Zealand","f":518000,"m":"cw","z":11,"t":"0:00:15","rt":0,"rs":"0:00:00","e":"","a":"192.168.1.2"},{"i":1},{"i":2},{"i":3}]

So a JSON array with as many objects as there are rx channels. Many of the fields can be an empty string value if there is no info.

• i: channel index
  
• n: name/callsign field, URI encoded
  
• g: geolocation, URI encoded
  
• f: freq Hz
  
• m: mode
  
• z: zoom level 0-14
  
• t: connect time h:mm:ss
  
• rt: time remaining type: 0 = no limit, 1 = inactivity limit will expire first, 2 = /24 hr limit will expire first
  
• rs: time remaining h:mm:ss (inactivity or /24 hr)
  
• e: extension in use
  
• a: user's ip address (as you would see on admin status tab)
  

Please ignore the "L" stuff mentioned above. I forgot it's only present when you run the Kiwi server in "foreground" debug mode. You won't see it when looking at the admin log or syslog when the usual background server is running. But the result is the same: the admin log tab shows a mix of messages, some of which won't be logged to the syslog.

v1.334 has a new switch on the WSPR entry of the admin "extensions" tab that allows decodes from WSPR auto-run tasks and use of the WSPR extension to be logged to the syslog. The effect is immediate. No restart is required.