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/Makefile.inc -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 https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: ********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: 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/edata_always-7b88bc.sh clang: note: diagnostic msg:
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.
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':
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:
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 https://beagleboard.org/upgrade ? When I run it the "apt update" inside the sudo tools/update_kernel.sh script just hangs at one of the repo updates.
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.
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.
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.
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.
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).
[edit]
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/update_kernel.sh I got these errors:
ERROR: The certificate of ‘rcn-ee.com’ is not trusted.
ERROR: The certificate of ‘rcn-ee.com’ 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/update_kernel.sh 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 192.168.8.1:807x 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 wsprdameon.sh.
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.
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.
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.
Comments
Attachments:
https://forum.kiwisdr.com/uploads/Uploader/6f/a808a9f9442e32e011ded188dcd687.png
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.
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?
Thanks
Mike
WB8CXO
Stu
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/Makefile.inc -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 https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg:
********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
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/edata_always-7b88bc.sh
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
root@beaglebone:
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': root@beaglebone:~/Beagle_SDR_GPS#
Do a
ps laxorhtopand see if the WS seems to be running. It might show up as a process containinglightdmin the name. If so, do this: v1.418 is being tested that makes those compiles smaller.I will upgrade to V1.418 once it appears on my Update page.
Thanks for the guidance.
Is anyone else having problems running the BBAI update procedure from https://beagleboard.org/upgrade ? When I run it the "apt update" inside the
sudo tools/update_kernel.shscript just hangs at one of the repo updates.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.
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.
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).
[edit]
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/update_kernel.sh I got these errors:
ERROR: The certificate of ‘rcn-ee.com’ is not trusted.
ERROR: The certificate of ‘rcn-ee.com’ 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/update_kernel.sh 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 192.168.8.1:807x 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 wsprdameon.sh.
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.
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
/sys/class/thermal/thermal_zone0/temp
A cron script could be written to run at the OS level to do that
Something like this
nano temp.sh:#!/bin/bashtemp=$(cat /sys/class/thermal/thermal_zone0/temp)if [ $temp -gt 65000 ]thenshutdown nowfiAdd execute right for file
chmod +x temp.shand add its running intocrontab -eunder rootHas 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.)
73
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.