jks

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

[updated 4-Mar-24]
SUBSEQUENT UPDATES:
If you subsequently update the Beagle software on your AI, and that update installs a new kernel,
then you will have to reinstall the kernel-related Kiwi changes manually as follows.
First, make sure you are running the latest Kiwi update.
Then type:
cdp
mst
make install_kiwi_device_tree
reboot (not just a server restart, a full Beagle reboot)

[updated 9-Feb-22]
If you need to re-flash your BBAI with a Beagle Debian 9 factory image there are now instructions for doing so on the website: http://kiwisdr.com/quickstart/index.html#id-dload Afterwards, you will still need to follow the instructions below to install the Kiwi software. Currently there is no BBAI image file that already has the Kiwi software pre-installed.

[updated 3-Jun-21]
Do NOT power the Kiwi + BBAI combination from the Kiwi DC jack. The common-mode choke on the Kiwi board may not handle the combined current and can burn up. Power from the BBAI USB-C jack instead. The Kiwi board will receive power from the BBAI.

[original message 10/2019]

Using a BeagleBone AI with the KiwiSDR board is currently UNDER DEVELOPMENT and UNSUPPORTED.
Only attempt the following if you have Linux, system/networking admin and electronics skills.
Use at your own risk. We have NO RESPONSIBILITY if you burn up your BBAI and/or Kiwi due to improper cooling/operation.

REQUIRED:
You MUST monitor the BBAI cpu temperature via the Kiwi stats UI or shell commands. Try and keep the temp below 50C.
You sometimes get weird behavior above 50C I've found even though 50C isn't really that hot.
Use a 90 mm diameter or larger fan that moves *lots* of air. Point it at end of the board stack with the SMA connectors to maximize BBAI cpu cooling.
You could wire the fan to the black/red wires of a very short, cutoff USB-A cable that plugs into the BBAI USB back by the sd card slot.
Do NOT use the Kiwi metal enclosure with its stock 30mm fan. That fan will not move enough air across the cpu heatsink.
See later posts in this thread for examples of modified enclosures that are reported to work.
Use a 5V 3A minimum USB-C power supply.

HARDWARE NOTES:
BBAI WiFi has not been validated. Use Ethernet instead.
More optimized cooling has not been finalized.
e.g. smaller fan, different heatsinks, header risers to increase inter-board spacing, enclosure effects.
Note that the micro sd card slot is inverted compared to the Beaglebone Black/Green (i.e. flip cards over compared to BBB/G).

STATUS:
14-channel mode can be enabled (BBAI only) on admin "mode" tab.
14 simultaneous kiwirecorder connections can get audio underruns unless running at 1.5 GHz. This is being debugged.
Running more than 6 WSPR extensions doesn't work as well as first thought. This is being debugged.
Remember that you can put something like this in a bookmark:
my_kiwi:8073/?ext=wspr,40m&mute&win2&ext=wspr,30m&mute&win3&ext=wspr,20m&mute etc.

FIRST TIME SETUP:
Find Ethernet ip address assigned by your DHCP. Login using ssh/PuTTY as "debian" "temppwd".
"sudo bash" to get a root shell. With this Debian distro you cannot login as "root" [no password] anymore, i.e. it's more secure.

Use the instructions at the following webpage to update/upgrade the BBAI software:
Leave out the use of "sudo" as you are already root.

Important: Do not install the TI deep learning tools listed at the end of the "update distribution components" section ("install -y ti-tidl mjpg-streamer-opencv-python").

**Ignore** the sections about WiFi, USB and Cloud9. WiFi has not yet been tested with the Kiwi software.
====> https://beagleboard.org/upgrade

After rebooting from the update login again and from a root shell do:
cd [goes to /root]
git clone https://github.com/jks-prv/Beagle_SDR_GPS.git
cd Beagle_SDR_GPS
make clean
make
make install

Will take a while (up to 40 minutes) as many packages have to be installed prior to building the Kiwi software.
Press the return key when prompted to reboot.
Kiwi server should be running ~45 seconds after reboot.

After the install/reboot the shortcut aliases in /root/.bashrc are available and also
tools for monitoring the cpu temperature and tuning the frequency (see "BBAI" section of /root/.bashrc).

Type "cf1" to set clock freq to 1 GHz from the default 500 MHz.
Type "ct" to check cpu temp (divide by 1000 for deg C).
Type "cm" for a continuous freq/temp monitoring.
Type "ht" for a nice process viewer to see cpu usage.

XXX Only use "cf15" to run at 1.5 GHz if you have sufficient cooling airflow! XXX
Monitor your cpu temp carefully!

[updated 4-Mar-24]
SUBSEQUENT UPDATES:
If you subsequently update the Beagle software on your AI, and that update installs a new kernel,
then you will have to reinstall the kernel-related Kiwi changes manually as follows.
First, make sure you are running the latest Kiwi update.
Then type:
cdp
mst
make install_kiwi_device_tree
reboot (not just a server restart, a full Beagle reboot)

[updated 9-Feb-22]
If you need to re-flash your BBAI with a Beagle Debian 9 factory image there are now instructions for doing so on the website: http://kiwisdr.com/quickstart/index.html#id-dload Afterwards, you will still need to follow the instructions below to install the Kiwi software. Currently there is no BBAI image file that already has the Kiwi software pre-installed.

[updated 3-Jun-21]
Do NOT power the Kiwi + BBAI combination from the Kiwi DC jack. The common-mode choke on the Kiwi board may not handle the combined current and can burn up. Power from the BBAI USB-C jack instead. The Kiwi board will receive power from the BBAI.

[original message 10/2019]

Using a BeagleBone AI with the KiwiSDR board is currently UNDER DEVELOPMENT and UNSUPPORTED.
Only attempt the following if you have Linux, system/networking admin and electronics skills.
Use at your own risk. We have NO RESPONSIBILITY if you burn up your BBAI and/or Kiwi due to improper cooling/operation.

REQUIRED:
You MUST monitor the BBAI cpu temperature via the Kiwi stats UI or shell commands. Try and keep the temp below 50C.
You sometimes get weird behavior above 50C I've found even though 50C isn't really that hot.
Use a 90 mm diameter or larger fan that moves *lots* of air. Point it at end of the board stack with the SMA connectors to maximize BBAI cpu cooling.
You could wire the fan to the black/red wires of a very short, cutoff USB-A cable that plugs into the BBAI USB back by the sd card slot.
Do NOT use the Kiwi metal enclosure with its stock 30mm fan. That fan will not move enough air across the cpu heatsink.
See later posts in this thread for examples of modified enclosures that are reported to work.
Use a 5V 3A minimum USB-C power supply.

HARDWARE NOTES:
BBAI WiFi has not been validated. Use Ethernet instead.
More optimized cooling has not been finalized.
e.g. smaller fan, different heatsinks, header risers to increase inter-board spacing, enclosure effects.
Note that the micro sd card slot is inverted compared to the Beaglebone Black/Green (i.e. flip cards over compared to BBB/G).

STATUS:
14-channel mode can be enabled (BBAI only) on admin "mode" tab.
14 simultaneous kiwirecorder connections can get audio underruns unless running at 1.5 GHz. This is being debugged.
Running more than 6 WSPR extensions doesn't work as well as first thought. This is being debugged.
Remember that you can put something like this in a bookmark:
my_kiwi:8073/?ext=wspr,40m&mute&win2&ext=wspr,30m&mute&win3&ext=wspr,20m&mute etc.

FIRST TIME SETUP:
Find Ethernet ip address assigned by your DHCP. Login using ssh/PuTTY as "debian" "temppwd".
"sudo bash" to get a root shell. With this Debian distro you cannot login as "root" [no password] anymore, i.e. it's more secure.

Use the instructions at the following webpage to update/upgrade the BBAI software:
Leave out the use of "sudo" as you are already root.

Important: Do not install the TI deep learning tools listed at the end of the "update distribution components" section ("install -y ti-tidl mjpg-streamer-opencv-python").

**Ignore** the sections about WiFi, USB and Cloud9. WiFi has not yet been tested with the Kiwi software.
====> https://beagleboard.org/upgrade

After rebooting from the update login again and from a root shell do:
cd [goes to /root]
git clone https://github.com/jks-prv/Beagle_SDR_GPS.git
cd Beagle_SDR_GPS
make clean
make
make install

Will take a while (up to 40 minutes) as many packages have to be installed prior to building the Kiwi software.
Press the return key when prompted to reboot.
Kiwi server should be running ~45 seconds after reboot.

After the install/reboot the shortcut aliases in /root/.bashrc are available and also
tools for monitoring the cpu temperature and tuning the frequency (see "BBAI" section of /root/.bashrc).

Type "cf1" to set clock freq to 1 GHz from the default 500 MHz.
Type "ct" to check cpu temp (divide by 1000 for deg C).
Type "cm" for a continuous freq/temp monitoring.
Type "ht" for a nice process viewer to see cpu usage.

XXX Only use "cf15" to run at 1.5 GHz if you have sufficient cooling airflow! XXX
Monitor your cpu temp carefully!

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

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

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