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.

It's too early to be certain, but some of the changes being developed for the AI might offer advantages to existing Kiwis using BBB/Gs. Example: Using a separate process to handle the stall caused by the synchronous-I/O-only SPI interface gives some cpu cycles back to other Kiwi tasks. Like doing more waterfall FFTs or whatever (this is the "kiwi.spi" process seen in the ht command in the prior post).

I also have a new idea to reduce the number of FPGA memory blocks (BRAMs) required to hold all the waterfall CIC output -- the dominant consumer of BRAMs by far. It requires two smaller buffers in a ping-pong configuration and a very carefully crafted bin packing algorithm to place waterfall samples in the buffers at precisely the right time. The Kiwi design document talks about why this is such a tricky issue (the "acquisition time problem") and explains why such a brute-force solution is currently used.

For example the rx4_wf4_12k config is currently using 100% of the BRAMs. rx8_wf2_12k only uses 80% but is limited by BBB/G cpu cycles. Same for 3rx_3wf_20k. Getting waterfall BRAMs freed up could possibly allow the number of channels to increase, assuming enough Beagle cpu cycles can be found.

The whole Kiwi design process is very much reminiscent of Whac-a-Mole. Good thing we kept the hardware so flexible (programmable)..

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.

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.

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.

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

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.