jks

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.

Tremendous thanks to Pierre for providing this service to the Kiwi community over the years and for his efforts with this latest update.

Note that map tiles for Leaflet are now served by the same provider used by the TDoA extension and admin page GPS tab maps. This means KiwiSDR is paying for those tile serves out of the profits from selling KiwiSDRs (same as we do for the charges incurred in running the proxy service).

Tremendous thanks to Pierre for providing this service to the Kiwi community over the years and for his efforts with this latest update.

Note that map tiles for Leaflet are now served by the same provider used by the TDoA extension and admin page GPS tab maps. This means KiwiSDR is paying for those tile serves out of the profits from selling KiwiSDRs (same as we do for the charges incurred in running the proxy service).

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.