I cannot share the app, but it would be pretty easy to strip it down, so that it only scans for Bluetooth. We’d need to see if it still shows the same issue.
Give me 1-2 days to do that.
Thanks!
Hi,
I have built a stripped down version of the app that can be deployed. Please find the repo here.
It come with a Makefile to compile and push to the BalenaCloud. The push target will build and push the ARM version to the blescanner app.
Expected broken behavior:
- Deploy the
blescannerapp to BBGW (make push) - App will show every 10s in the console some number of detected bluetooth devices (at least one discovered device per 10s).
- After ~2 days no bluetooth devices will be discovered.
- The dead man switch will exit the app and stop the container.
- Subsequent attempt to restart the container by BalenaOS will fail due to the lack of discovered bluetooth devices.
- Rebooting the BBGW will fix the problem and show discovered beacons.
Please let me know if you have any issues.
Thanks Erich, I was pass this on to our OS team for review.
Hi Erich, just an update to let you know that this is still in our queue. I expect to have an update by next week.
Thank you for the update! Our plan is to trial our device in 2 weeks. Is it reasonable to assume that we would have a solution by then or should I work on plan B?
Hi Erich, as you know both the hardware, as it works with Debian, and BalenaOS are working (as it works on a RaspberryPi3/4), I think we can assume we can identify and fix the problem. However, I can’t provide guarantees that this will happen in the 2 weeks period, so I would suggest you try a different device type to have a backup plan for the trial. I can suggest the Balena Fin as it contains a Raspberry Pi CM3/3+, and has the option of an external uFL antenna.
Also, if you happen to have any device on the failed state I would be interested to check whether sshing to the host OS you see any devices when scanning for them with:
bluethoothctl
power on
scan on
And also installing the bluez package in your Alpine container, check whether devices are discovered when scanning from the container:
export DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket
bluetoothctl
power on
scan on
Could you also please confirm that the Debian Buster IoT image you are using are the ones from https://debian.beagleboard.org/images/bone-debian-10.3-iot-armhf-2020-04-06-4gb.img.xz with:
22448ba28d0d58e25e875aac3b4e91eaef82e2d11c9d2c43d948ed60708f7434 bone-debian-10.3-iot-armhf-2020-04-06-4gb.img.xz
?
Yes, that is the image I’m using.
Give me a day to try your suggestions.
Great! Keep us posted!
Hi, just following up.
Were you able to try Alex’s suggestions?
Sorry, finally got around to try it:
On host OS:
root@6875552:~# export DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket
root@6875552:~# /usr/bin/bluetoothctl
dbus[14230]: arguments to dbus_connection_get_object_path_data() were incorrect, assertion "connection != NULL" failed in file ../../dbus-1.12.10/dbus/dbus-connection.c line 5905.
This is normally a bug in some application using the D-Bus library.
D-Bus not built with -rdynamic so unable to print a backtrace
Aborted
However when I adjust the path removing the host component, I get this on the Host OS:
root@6875552:~# export DBUS_SYSTEM_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socketroot@6875552:~# /usr/bin/bluetoothctl
Agent registered
[bluetooth]# power on
No default controller available
[bluetooth]# scan on
No default controller available
On the container OS:
bash-5.0# export DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket
bash-5.0# /usr/bin/bluetoothctl
Agent registered
[bluetooth]# power on
No default controller available
[bluetooth]# scan on
No default controller available
[bluetooth]#
Hi there,
Thanks for the update. I’ll let the folks who are debugging it here know.
Cheers,
James.
Hi, just a brief update on this one. We have gone looking for bluetooth related differences between Debian Buster and BalenaOS. The bluetooth firmware used by both is identical, as well as the bluez version. Also, they are both using the same baudrate when attaching the HCI device. In summary, there are no obvious differences that could cause the problem described.
I have a BBGW running the provided application and plan to leave it running for a few days. Hopefully once the issue is reproduced I will be able to debug it further.
Hi, one more question. Are you using the WiFi while performing the bluetooth detection test? I suspect that WiFi/Bluetooth co-existence (there is only one radio chip that has to be shared) and/or 2.4GHz interference might be causing issues.
- Where you also using the WiFi when testing with Debian Buster?
- Could you retest BalenaOS with the WiFi interface down?
Yes, I was using Wifi & Bluetooth concurrently in both case (Docker & baremetal).
How do you want me to bring down the Wifi interface?
I presume it would be ok to use a USB-Ethernet dongle to access the machine?
Hey there,
In testing we found that the WiFi is interfering. A USB-Ethernet dongle should be fine.
To disable wifi:
nmcli c delete resin-wifi-01
rmmod wl18xx
rmmod wlcore
Let us know how it goes.
Lucy-Jane
Hi,
Per your recommendation I installed a USB-Ethernet dongle. I checked that the original Wifi adapter was not present anymore and only my new eth0 adapter could be used to connect to the Internet.
I just checked after 4 days and despite not using the built-in Wifi adapter anymore the Bluetooth chip is still getting into a state where it doesn’t see any Bluetooth devices anymore.
Any other ideas on what is going on and how to fix it? I’m pretty much at the end of my wits.
Can I ask the container to trigger a reboot (maybe by calling the Balena API)? I know this is pretty ugly, but I need to get something working somehow.
Hi there.
You can trigger an on-device reboot using the supervisor API. That said, as you pointed out it’s not a solution to the problem. I would avoid it if possible.
It looks like our team is still working on reproducing this issue. I’ll ask them to get back to you with an update as soon as they can.
Cheers,
James.