jks

I changed the kiwiclient / kiwirecorder repo to point to https://github.com/rrobinett/wsprdaemon instead of including a copy of it.

And you've probably noticed there is a new forum category "WSPR, wsprdaemon, kiwirecorder". Should hopefully make it easier to find things.

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)..

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

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)..