jks

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.

I have this working now already. It will be in the next release in a day or two.

There are two types of messages shown on the "log" tab of the admin page. Messages containing "L" are also logged to the Linux system log that is kept on the filesystem and is shown when you use the ml or msl commands. Like this:

Thu Sep 26 11:08:08 00:00:10.994 ....      L sdr.hu registration: WORKED

Messages without the "L" are not saved in the Linux log, mostly because they are for debugging or more frequent and would tend to fill up the filesystem eventually.

Currently the decode messages from the WSPR extension are not "L" messages for this reason. And that is why you don't find them in the system log. However, this could be made an option on the WSPR section of the extensions tab.

Might be someone sampling Navtex (490, 518 kHz) data. The Kiwi Navtex decoder extension tunes to 517.5/CW so the default CW passband center is at 500 Hz for the FSK decoder. But custom sampling code might be tuning to 517/USB where the 1 kHz offset of 518 kHz would still be within the default USB passband. This is a little inefficient as the passband is wider than it needs to be for optimal FSK decoding. But who knows..

We've had two reports of waterfall display "jitter" when new lines are being added to the display. It's important to note that "jitter" in this case does not mean the uneven rate at which new lines are added (people have complained about that for a long time, lol). It means the entire waterfall window actually jumps up and down slightly. This behavior also is reported to stop when spectrum mode is enabled ("Spec" button). The problem may be related to the use of older version browsers.

We have not seen this problem in any of our testing configurations. If anyone else has please let us know details (browser type and version, pc or mobile, Kiwi used etc.)
Thanks!