jks

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

v1.374 has a new, more accurate TDoA algorithm from Christoph. It is used by default. There is a checkbox "Old algorithm" in the TDoA options column at top right to revert/compare. Also, you can use the URL parameter "old:" if necessary.

Yes, there's something wrong currently with multiple instances of DRM on the AI. I used to be able to run 4 of them and they used less than 100% of cpu1. But now even a single instance is over 50%. So something has changed. I haven't had time to look at AI issues recently. DRM or otherwise.

Read the FAQ (https://sdr.hu/register#faq) and note the emphasis on no commercial, government or military use of the list. Doing some rudimentary checking on ham callsigns is really his only option. Then look at his blog (https://blog.sdr.hu) and the discussion of his battles with the ethics of open source over the years.

We at KiwiSDR are happy Andr?s allows us to use his work and that he continues to be a Kiwi profit-sharing partner since our startup in 2016.