jks

Well, you can force the AI to run at 500 MHz. But the Kiwi server may have problems at that clock rate. From a shell window (via ssh/PuTTY connection or admin console tab) use the command "cf5". Then "cf" to check that it actually switched. Remember that the BBB/BBG runs at 1 GHz (fixed).

Other commands are:

cf15 = 1.5 GHz
cf11 = 1.176 GHz
cf1  = 1 GHz

v1.377 contains a fallback that retries the git pull using a fixed ip address for github.com. Interestingly, about half way through checking the fix on Tony's Kiwi the git pull to github.com (using the domain name) started working. So that means this was probably a mirror server configuration issue by Github as opposed to an ISP issue. Anyway, the fix is in and will hopefully save someone some grief in the future.

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

I don't know. If there is no code running that requires GPU cycles then I can't imaging it burns any power on its own just sitting idle.

Hi John. Yes, probably. The algorithm chosen for the GPS update of the ADC XO frequency was checked by opening the door to the outside (on a winter's day) that is adjacent to where the Kiwi is developed and watching what happened. At the time the GPS time/position output was a lot noisier than it is now (thanks Christoph!) so that was the tradeoff. And of course the whole thing is not a PLL (and definitely not a GPSDO). It's more of a FLL.

Happy to see Voice of Nigeria using DRM mode C instead of the usual mode B to combat the selective fading and other problems. Even if it means their bit rate drops to 9.1 kbps (see table 5.2 "DRM system bit rates" page 21 https://www.drm.org/wp-content/uploads/2019/02/DRM-Handbook.pdf, bit rate also because MSC using 16-QAM and protection level=0). Also note their transmitter is ~110 Hz low, lol.

When HF broadcasters switch to using the xHE-AAC codec (like India uses for MW) they should get better audio quality using lower bit rates.

Providing this information via a URL opens up a lot of cans of worms I don't have time to deal with. You can't provide user info accessible to anyone (like /status) because the privacy crowd will show up with torches and pitchforks (we've had enough trouble in the past with the issue of user ip addresses and geolocations). And you can't add a quick and easy authentication scheme (like adding the admin password in cleartext to the URL) without the security people jumping down my throat again.

@arnie: Station name in Chinese (via UTF8) is in today's v1.375 release. Thanks for mentioning that.

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.

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.