Kiwi BBAI software installation instructions [updated 4-Mar-24]



  • I am finally getting to setting up the AI and I am getting the following errors.

  • Disregard,, all up and running.. would help if I completed the update the under Root...
  • edited July 2020

    temp is staying steady at 44-45c with 13 RX. single 25mm fan bolted to cpu, exhaust up, and a small 1" centrifugal blower transverse the heat sink.
  • I'm trying to bring up a BB AI and get these messages from time to time.

    Message from syslogd@beaglebone at Sep 30 05:37:54 ...
    kernel:[ 2747.035628] Internal error: : 1406 [#1] PREEMPT SMP ARM

    Message from syslogd@beaglebone at Sep 30 05:37:54 ...
    kernel:[ 2747.429178] Process lxqt-panel (pid: 2662, stack limit = 0xd14f6218)

    Message from syslogd@beaglebone at Sep 30 05:37:54 ...
    kernel:[ 2747.443085] Stack: (0xd14f7f40 to 0xd14f8000)

    Message from syslogd@beaglebone at Sep 30 05:37:54 ...
    kernel:[ 2747.452551] 7f40: d2676140 d2676100 d2676140 00000006 d14f7f74 d14f7f60 c0cdbba0 c016cc00

    Message from syslogd@beaglebone at Sep 30 05:37:54 ...
    kernel:[ 2747.468986] 7f60: 0000001e d2676100 d14f7f94 d14f7f78 c031d24c c0cdbb8c 0106e508 b5ed9bec

    Message from syslogd@beaglebone at Sep 30 05:37:54 ...
    kernel:[ 2747.485420] 7f80: 00000000 00000006 d14f7fa4 d14f7f98 c02f6d78 c031d230 00000000 d14f7fa8

    Message from syslogd@beaglebone at Sep 30 05:37:54 ...
    kernel:[ 2747.498716] 7fa0: c0108d40 c02f6d54 0106e508 b5ed9bec 0000001e 00000444 b5ed97a8 b5e3d759

    Message from syslogd@beaglebone at Sep 30 05:37:54 ...
    kernel:[ 2747.514977] 7fc0: 0106e508 b5ed9bec 00000000 00000006 00000000 b5c1c200 0000ffff 00000100

    Message from syslogd@beaglebone at Sep 30 05:37:54 ...
    kernel:[ 2747.532110] 7fe0: 00000006 be93ea2c b5e3d765 b5e076f6 200f0030 0000001e 00000000 00000000

    Message from syslogd@beaglebone at Sep 30 05:37:54 ...
    kernel:[ 2747.608278] Code: e3001c1b e34c00fc ebff47b7 e89da8f0 (e3a00000)

    I'm way over my head just following instructions and googling for hours trying to figure things (linux) out.

    Issues with the kernel can't be good. Never seen them on the other Kiwi/BBG.

    Should I just start over? Perhaps an error I made somewhere in the process or garbaged code?


  • I have done 6 of them and always just followed the instructions at the very start of this thread, and had no issues
  • Mike, how are you powering, and cooling the device?
  • My compile fails.
    After performing an upgrade + update on Buster on the BBAI, I followed instructions at the top of this thread to 'make clean; make' and after compiling many files, a compile repeatedly fails on the same file:

    make[1]: Leaving directory '/root/Beagle_SDR_GPS'
    make[1]: Entering directory '/root/Beagle_SDR_GPS'
    clang++-7 -Dv1_417 @../build/gen/ -c -o ../build/obj_keep/edata_always.o ../build/gen/edata_always.cpp
    clang: error: unable to execute command: Killed
    clang: error: clang frontend command failed due to signal (use -v to see invocation)
    clang version 7.0.1-8~deb9u4 (tags/RELEASE_701/final)
    Target: armv7l-unknown-linux-gnueabihf
    Thread model: posix
    InstalledDir: /usr/bin
    clang: note: diagnostic msg: PLEASE submit a bug report to and include the crash backtrace, preprocessed source, and associated run script.
    clang: note: diagnostic msg:

    Preprocessed source(s) and associated run script(s) are located at:
    clang: note: diagnostic msg: /tmp/edata_always-7b88bc.cpp
    clang: note: diagnostic msg: /tmp/
    clang: note: diagnostic msg:

    Makefile:745: recipe for target '../build/obj_keep/edata_always.o' failed
    make[1]: *** [../build/obj_keep/edata_always.o] Error 254
    make[1]: Leaving directory '/root/Beagle_SDR_GPS'
    Makefile:100: recipe for target 'all' failed
    make: *** [all] Error 2
  • jksjks
    edited November 2020
    This is a symptom of running out of memory while compiling the in-memory filesystem "edata_always" (of Kiwi-related files). Try rebooting Debian and rebuilding again (without the "make clean" so it doesn't take forever). If it continues to fail I will have to split-up the compiling process.
  • edited November 2020
    I tried a reboot followed only by a 'make' and got the same error.
    On the 1 GB Pi 4 I need to disable the console GUI to free enough memory to run wsprdaemon.
    Is there a similar way to free memory on the BBAI by disabling its console GUI?

    Your diagnosis seems to be validated by this 'vmstat -tw 2' which I ran at the same time as 'make':
     1  0            0        55588        14856       183852    0    0     0     0  445  450  52  10  38   0   0 2020-11-04 21:58:31
     1  0            0        51920        14864       183852    0    0     0     8  469  500  51  12  37   0   0 2020-11-04 21:58:33
     1  0            0        48568        14864       183852    0    0     0     0  461  474  51  10  38   0   0 2020-11-04 21:58:35
     1  0            0        46520        14864       183852    0    0     0     0  492  506  52  11  38   0   0 2020-11-04 21:58:37
     2  0            0        40828        14864       183852    0    0     0     2  484  514  51  11  38   0   0 2020-11-04 21:58:39
     1  0            0        38848        14864       183852    0    0     0     0  454  485  52  11  38   0   0 2020-11-04 21:58:41
     1  0            0        36868        14864       183852    0    0     0     0  461  493  52  11  38   0   0 2020-11-04 21:58:43
     1  0            0        25708        14864       185892    0    0  1020     0  529  578  49  13  38   0   0 2020-11-04 21:58:45
     1  0            0         5640        14568       179536    0    0     0     0  894  551  46  20  34   0   0 2020-11-04 21:58:47
     1  0            0        10676         9596       156604    0    0     0     0 3592  572  41  30  29   0   0 2020-11-04 21:58:49
     2  0            0         4976          140       144484    0    0     0     0  646  571  47  19  34   0   0 2020-11-04 21:58:51
    procs -----------------------memory---------------------- ---swap-- -----io---- -system-- --------cpu-------- -----timestamp-----
     r  b         swpd         free         buff        cache   si   so    bi    bo   in   cs  us  sy  id  wa  st                 UTC
     3  0            0         4284         1068       113096    0    0  2472     0 3452  976  41  33  24   1   0 2020-11-04 21:58:53
     5  0            0         7948         1068        87200    0    0   110     0 1494  582  43  24  32   0   0 2020-11-04 21:58:55
     2  3            0        85828          252        78500    0    0 13180    14 4296 1836  23  38  37   2   0 2020-11-04 21:58:58
     2  0            0       229960         2648       131948    0    0 27654     0 2496 3473  22  40  31   6   0 2020-11-04 21:59:00
     1  0            0       223984         3576       136360    0    0  2676     0  844 1037  48  14  38   0   0 2020-11-04 21:59:02
     0  0            0       231720         4000       146580    0    0  1056  4250  736  916  22  20  55   3   0 2020-11-04 21:59:04
     1  0            0       231748         4000       146580    0    0     0     0  284  474   2  11  88   0   0 2020-11-04 21:59:06
  • jksjks
    edited November 2020
    The Kiwi Makefile disables the Debian window system. But when you arbitrarily update/upgrade on an otherwise working system you always run the risk of the WS becoming re-enabled in a way the Kiwi build procedure doesn't detect. This is the same old argument we had with Debian 8 on stock Kiwis. We don't routinely test the Kiwi software against all possible Debian/Beagle distros. If we did nothing else would get done. Same reason we don't touch WiFi dongles. Proverbial can of worms. The forum is a testament to that.

    Do a ps lax or htop and see if the WS seems to be running. It might show up as a process containing lightdm in the name. If so, do this:
    systemctl stop lightdm.service
    systemctl disable lightdm.service
    v1.418 is being tested that makes those compiles smaller.
  • v1.418 is out. Even though your current build is failing you should be able to run "ku" to bring up the last working server. It should be able to download v1.418. The changes to reduce the compile size are all in the Makefile(s). So a build of v1.418 should work even if v1.417 doesn't.
  • Once I disabled the WS there was enough memory for the make of V1.417 to complete.
    I will upgrade to V1.418 once it appears on my Update page.
    Thanks for the guidance.
  • Okay, sounds like I should also disable the WS on each BBAI build. I thought an update/upgrade to the WS package would have respected the last manually-set systemctl disable state. But I guess not.
  • Is anyone else having problems running the BBAI update procedure from ? When I run it the "apt update" inside the sudo tools/ script just hangs at one of the repo updates.

    #sudo tools/ 
    info: checking archive
    2021-04-12 23:48:33 URL: [222/222] -> "LATEST-ti" [1]
    Kernel Options:
    ABI:1 LTS41 4.1.30-ti-r70
    ABI:1 LTS44 4.4.155-ti-r155
    ABI:1 LTS49 4.9.147-ti-r121
    ABI:1 LTS414 4.14.108-ti-r140
    ABI:1 LTS419 4.19.94-ti-r61
    ABI:1 LTS54 5.4.106-ti-r26
    ABI:1 LTS510 5.10.21-ti-r1
    Kernel version options:
    LTS414: --lts-4_14
    LTS419: --lts-4_19
    LTS54: --lts-5_4
    LTS510: --lts-5_10
    info: you are running: [4.14.108-ti-r123], latest is: [4.14.108-ti-r140] updating...
    Ign:1 stretch InRelease
    Get:2 stretch-updates InRelease [93.6 kB]
    Get:3 stretch InRelease [3,076 B]     
    Get:4 stretch/updates InRelease [53.0 kB]    
    Get:5 stretch Release [118 kB]   
    Get:6 stretch Release.gpg [2,410 B]
    Get:7 stretch-updates/main armhf Packages.diff/Index [15.0 kB]
    Get:8 stretch-updates/main armhf Contents (deb).diff/Index [11.1 kB]
    Get:9 stretch-updates/main armhf Packages 2020-06-07-1403.53.pdiff [466 B]
    Get:10 stretch/main armhf Packages [1,604 kB]
    Get:11 stretch-updates/main armhf Packages 2020-07-16-2008.14.pdiff [30 B]
    Get:11 stretch-updates/main armhf Packages 2020-07-16-2008.14.pdiff [30 B]
    Get:12 stretch-updates/main armhf Contents (deb) 2020-06-07-1403.53.pdiff [1,525 B]
    Get:13 stretch-updates/main armhf Contents (deb) 2020-07-16-2008.14.pdiff [134 B]
    Get:13 stretch-updates/main armhf Contents (deb) 2020-07-16-2008.14.pdiff [134 B]
    Get:14 stretch-updates/non-free armhf Packages [628 B]
    Get:15 stretch-updates/non-free armhf Contents (deb) [185 B]
    Get:16 stretch/updates/main armhf Packages [643 kB]
    Get:17 stretch/updates/non-free armhf Packages [5,320 B]        
    Get:18 stretch/main armhf Packages [6,908 kB]                   
    Get:19 stretch/main armhf Contents (deb) [31.4 MB]
    Get:20 stretch/contrib armhf Packages [41.8 kB]
    Get:21 stretch/contrib armhf Contents (deb) [80.3 kB]
    Get:22 http// stretch/non-free armhf Packages [59.8 kB]
    Get:23 stretch/non-free armhf Contents (deb) [757 kB]
    98% [19 Contents-armhf store 0 B]                                                                                   
    (hangs here)

  • Never mind, one of the repo sites was just being slow. It took almost 9 minutes to update from it 🙄

  • Important: The BBAI setup instructions (first post in this thread) have been amended. We no longer recommend powering the Kiwi + BBAI combination from the Kiwi DC input jack. Use the BBAI USB-C input instead.

  • rework to follow here... 4 times!

    I am going to do it with eBay item 173898127317

  • received my adapters... work great, minimal down time

  • A simple search using the item number didn't return anything for me. But using the advanced search page with "completed listings" checked did. Pretty nifty little adapters.

  • edited June 2021

    Just a reminder about:

    which included my offer to provide 3D print file for a clamp which can protect BBG USB connector from damage.

    The SMD USB connector on the BB is so fragile that I fear anyone using a right angle adapter or cable without it will risk breaking the connector away from the PCB, as I did more than once and which prompted creation of the plastic clamp to prevent it.

    I may even have an exta printed clamp or two around here which could go to a good home, should that help someone. In any case, only a relatively short time is required to print one for yourself on almost any 3D printer.

    Glenn n6gn

  • Just to clarify, these are two different, and important, modifications.

    BBAI: Jim's adapter from Ebay (2.1mm DC jack to USB-C) makes it easier to move the DC power cable for a BBAI-based Kiwi from the Kiwi board to the BBAI directly. This in response to our recent recommendation to move the DC input to the BBAI so as to not potentially over stress the CM choke on the Kiwi board due to the much higher current draw of the BBAI.

    BBG: Glenn's modification is to supply networking and DC power on a single cable to the (fragile) micro-USB connector of the BBG to avoid CM noise problems from the wired Ethernet connection. It does require adding a jumper to the BBG to increase the current allowed on the micro-USB above the USB standard 500 mA.

  • edited June 2021

    Yes, these are different topics but what they have in common is a mechanical support to keep the USB connectors from breaking. The same plastic piece necessary to keep the BBG power and USB connectors 'safe' can be adpated to protect the BBAI USBC connector as well.

    The two USB connectors are in different positions on the BBG and BBGAI but the plastic clamp can be made to help protect either of them as well as the Kiwi barrel power connector (which is no longer used with the BBAI).


    In thinking only a little more about @jks comment and the situation I'm thinking that a single solution like I have for both the BBG and BBAI is not practical. This because the heat sinking requirements of the BBAI and required airflow are greater and vary with the implementation. A large plastic piece may block too much of the available air flow for some cooling solutions so probably a separate BBAI clamp is a better idea.

    For myself, I've now avoided any connections whatsoever to the LAN end of the BBAI. I run a line internally to the 5V connection on the Kiwi PCB to the RF end where I have a special end plate to both bypass the SMAs (particularly at GPS frequencies) and provide operating power for the Kiwi and remote preamplifiers. The only wire sticking out of the LAN end is the WiFi antenna.

    To even use the original Al LAN-end plate, I had to nibble away some material to let the USBC protrude. Without doing that the end plate won't go on at all. I presume this is roughly what others have done but with air flow a serious issue for many, this may not be a common solution.

    I'm still open to making a special design but without knowing the target it may be hard to make a one-size-fits-all that is actually a good solution.

  • I saw Mouser had some KiwiSDR boards in stock, so I ordered one, along with a BBAI, which arrived today.

    I had a minor hiccup getting things going, when I ran tools/ I got these errors:

    ERROR: The certificate of ‘’ is not trusted.

    ERROR: The certificate of ‘’ has expired.

    I spent some time trying to get around that. Finally I jumped ahead and ran:

    apt update

    apt upgrade

    I noticed while that was running there was a mention of updating some certificates. Hmm... so I went back and ran tools/ and sure enough it worked fine this time.

    Otherwise the install went well. I have it configured for 14 audio only channels so I can use it along with various external decoding programs.

    I don't have a permanent setup yet, so I rigged a cooling fan in front of the boards:

    I added the headers between the boards to increase the spacing and maybe get some more airflow, and assuming the slightly longer lead length will not cause problems electrically/timing.

    At 1 GHz the CPU is 45c, but the ambient temperature here in the shack is 29c, so relatively speaking I am not sure how much better I can do.

    Now to find an SMA cable so I can connect to my high gain external GPS antenna splitter since I can never get a decent GPS signal here in the shack.

  • Per Tom, WA2TP's success, I've been running BBAI/Kiwi with extensions, inside a standard enclosure for quite some time now. I've used an external fan and a 3D printed shroud to force air through which keeps the temperature in the 40's.

    My main reason for doing this, beside the additional rx frequencies, is to be able to use the BBAI's WiFi and avoid common mode noise in/through the LAN cable.

    Even as yours sits, I suspect that will deliver WiFi'd access. I used Connmanctl to connect the BBAI automatically to my home WiFi/router and it seems to be fine even with all 14 receivers running WSPR via

    I know use of BBAI with Wifi is marked as "unproven" on the docs page but I've had no problem with it on two different BBAIs.

  • edited October 2021

    Hello I am using BBAI on some of my KiwiSDRs too and this is my cooling version.

    I replace radiator on the BB-AI board to Cu from Ali, install horizontal fan with USB connection and use Adafruit stacking header for Beagle Bone:

    CPU temp about 42-45C on 1.2GHz freq.

  • Since the KiwiSDR software monitors the BBAI CPU temperature, could a maximum value be entered in the admin page, and if this is exceeded (perhaps for N seconds) the KiwiSDR software initiates a shutdown, as safety measure in case the fan/cooling fails? This would be a good protection, IMHO.

  • The temp is readable in


    A cron script could be written to run at the OS level to do that

  • Something like this nano


    temp=$(cat /sys/class/thermal/thermal_zone0/temp)

    if [ $temp -gt 65000 ]


     shutdown now


    Add execute right for file chmod +x and add its running into crontab -e under root

  • Has anyone considered cooling the BB from the bottom? I looked down the thread but didn't see anyone attempting this. PCB material has pretty good thermal conductivity due to all that copper in the various ground and power planes. It should be fairly easy to use a big chunk of thermal pad material to thermally couple the bottom of the BB to either the case or a heat spreader. The chips effectively couple heat to the PCB through the pads. Seems like this would solve a host of problems.

    (The folks at Red Pitaya recommended this to me for their boards and it works rather well.)


  • I did look at it but the efficiency was meant to be low so didn't spend too long. Also the thermal pad is not great once thick enough to accommodate pins or components on the bottom.

    Let us know how you get on.

Sign In or Register to comment.