jks

Okay, there seems to be a couple of issues going on here.

1) I got screwed over by dropbox. The v1.383 img.xz file has the correct filename, contents and SHA on my laptop dropbox directory. But even after a dropbox sync a fetch of that file from dropbox returns the contents of the previous v1.46 img.xz file (as pointed out by Yuri) for reasons I don't understand. I used the usual procedure to get a dropbox file URL to insert into various places (e.g. Kiwi website, kiwiSDR-download-KiwiSDR-create-micro-SD-flasher.sh script, etc.) But I didn't actually check it because it's never failed before. I think it's okay everywhere now with one exception: The file Beagle_SDR_GPS/tools/kiwiSDR-download-KiwiSDR-create-micro-SD-flasher.sh in the distro on your Kiwi will have to wait for an update to a v1.384 release to be corrected.

2) Jeff mentions he had to manually install a github commit (e90f87d) which is one commit (91cbe70) before the full v1.383 release. But that last commit has to do with the changes to the flasher script and I can't see how it would influence the normal running of the system in any way. But I also have one other complaint in email of an update to v1.383 failing (no details known yet). So more investigation is needed. [update: it was just filesystem corruption that prevented an update from v1.374 to v1.383, and after a manual rebuild it now works fine]. I always test the full release on a bunch of beta Kiwis of different configurations to try and reduce the chances of bricking the world.

The password changes are bit subtle. You have to read the explanation topic on the forum carefully to decide if the password has been changed to the Kiwi admin password (if you have configured one) or the serial number of the Kiwi (written in black marker pen in the white box on the Kiwi PCB, also in the "network" tab of the admin page if you can get there).

Okay, there seems to be a couple of issues going on here.

1) I got screwed over by dropbox. The v1.383 img.xz file has the correct filename, contents and SHA on my laptop dropbox directory. But even after a dropbox sync a fetch of that file from dropbox returns the contents of the previous v1.46 img.xz file (as pointed out by Yuri) for reasons I don't understand. I used the usual procedure to get a dropbox file URL to insert into various places (e.g. Kiwi website, kiwiSDR-download-KiwiSDR-create-micro-SD-flasher.sh script, etc.) But I didn't actually check it because it's never failed before. I think it's okay everywhere now with one exception: The file Beagle_SDR_GPS/tools/kiwiSDR-download-KiwiSDR-create-micro-SD-flasher.sh in the distro on your Kiwi will have to wait for an update to a v1.384 release to be corrected.

2) Jeff mentions he had to manually install a github commit (e90f87d) which is one commit (91cbe70) before the full v1.383 release. But that last commit has to do with the changes to the flasher script and I can't see how it would influence the normal running of the system in any way. But I also have one other complaint in email of an update to v1.383 failing (no details known yet). So more investigation is needed. [update: it was just filesystem corruption that prevented an update from v1.374 to v1.383, and after a manual rebuild it now works fine]. I always test the full release on a bunch of beta Kiwis of different configurations to try and reduce the chances of bricking the world.

The password changes are bit subtle. You have to read the explanation topic on the forum carefully to decide if the password has been changed to the Kiwi admin password (if you have configured one) or the serial number of the Kiwi (written in black marker pen in the white box on the Kiwi PCB, also in the "network" tab of the admin page if you can get there).

It should work, but it is technically out-of-spec w.r.t. current draw on the P9-7,8 pins, although I don't think it's a big deal. What worries me more is the heat dissipation of the or-ing diodes especially since we discovered they are placed on the PCB directly under the PMIC (which has enough thermal dissipation problems of its own). My complaints are summarized here: https://github.com/beagleboard/beaglebone-ai/issues/10#issuecomment-533700514

In short, try it and see how it goes. Put a small heatsink on the PMIC if you can.

Happy to hear that.

Even though you plug power into the Kiwi board it is first routed to the Beagle and its power management chip (PMIC) for monitoring, protection and switching. From there it goes on to power the Beagle and then back over to the Kiwi board. The PMIC has an absolute maximum input voltage spec of +20 VDC. It won't power-on at that voltage (5.8V is the limit) but it's supposed to withstand it. So that's why you got away with applying 9V.

However we have had a couple Kiwi/Beagles expire when reverse input voltage was applied.

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)