jks

Below shows progress with an experiment to get a 14-channel configuration working using a BeagleBone AI. The challenge is to move as much processing to the second cpu core of the AI as possible so as not to impact the realtime requirements of serving the 14 audio channels (plus the usual 12-channel GPS etc.) It seems to work. A 14 audio DDC + 1 waterfall DDC configuration (rx14_wf1) was made to fit in the FPGA (LUTs now 97% full) by reducing the amount of CIC filtering logic slightly.

Note below that the processor temperature and clock speed are displayed. The cores are currently running at rate automatically adjusted based on temperature between 1.0 - 1.5 GHz due to the reduced cooling configuration I'm testing.



The Kiwi's internal WSPR extension is running on all 14 channels as a worst-case test since WSPR decoding is so cpu intensive. The fact that this works does not change the fact that Rob's wsprdaemon is the superior solution for anything but casual WSPR monitoring. In fact 14 channels was chosen in support of getting a single Kiwi to work in an all-band wsprdaemon setup.

Below is output from the Linux "ht" command. It shows how certain components of the software have been moved to new Linux processes separate from the main Kiwi process and "locked" to the second core of the processor. "kiwid" is the main process and is locked to cpu0 as seen in the "cpu" column. The other "kiwi.xxx" processes are locked to cpu1. Of interest here is the "kiwi.wsp" process which runs the collective WSPR decoding of all 14 channels.



This is just a progress report. There is a long list of work to do.

Below shows progress with an experiment to get a 14-channel configuration working using a BeagleBone AI. The challenge is to move as much processing to the second cpu core of the AI as possible so as not to impact the realtime requirements of serving the 14 audio channels (plus the usual 12-channel GPS etc.) It seems to work. A 14 audio DDC + 1 waterfall DDC configuration (rx14_wf1) was made to fit in the FPGA (LUTs now 97% full) by reducing the amount of CIC filtering logic slightly.

Note below that the processor temperature and clock speed are displayed. The cores are currently running at rate automatically adjusted based on temperature between 1.0 - 1.5 GHz due to the reduced cooling configuration I'm testing.



The Kiwi's internal WSPR extension is running on all 14 channels as a worst-case test since WSPR decoding is so cpu intensive. The fact that this works does not change the fact that Rob's wsprdaemon is the superior solution for anything but casual WSPR monitoring. In fact 14 channels was chosen in support of getting a single Kiwi to work in an all-band wsprdaemon setup.

Below is output from the Linux "ht" command. It shows how certain components of the software have been moved to new Linux processes separate from the main Kiwi process and "locked" to the second core of the processor. "kiwid" is the main process and is locked to cpu0 as seen in the "cpu" column. The other "kiwi.xxx" processes are locked to cpu1. Of interest here is the "kiwi.wsp" process which runs the collective WSPR decoding of all 14 channels.



This is just a progress report. There is a long list of work to do.

If you're interested in getting a Kiwi at a substantial discount then make sure you've hit the "requested" button on the drop.com site (https://drop.com/buy/seeed-kiwisdr-kit?mode=guest_open) [registration required]. "Requested" is an expression of interest, not a commitment.

It's been 3 months since the last drop ended and they used to occur back-to-back pretty much. There are plenty of Kiwis available after a recent factory build, so that's not the issue.

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

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)