jks

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.

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)
  

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.

Happy to see this. Greater appreciation and interest in distributed SDR applications is needed. So much that can be done..
https://www.rtl-sdr.com/electrosense-rtl-sdr-based-crowd-sourced-spectrum-monitoring-with-a-dc-to-6-ghz-rtl-sdr-up-downconverter

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!

Yes, there seems to be a different bug in older versions of the antenna switch extension that prevents rebuilds.
To update and rebuild follow these instructions:

cdp
mst    [stop Kiwi server]
m git    [make sure Kiwi software is updated]
cd
rm -rf extensions    [remove old extensions build directory]
cd ~/KiwiSDR-antenna-switch-extension
gup    [update ant switch from github]
bash ant-switch-extension-installer    [rebuild ant switch and Kiwi software]
[Kiwi server should now be running]

I was able to do this from an old (March 2018) version of the antenna switch without any problems.