Bluetooth - Printable Version +- Hilscher Community Forum (https://forum.hilscher.com) +-- Forum: netPI 3 - Docker featuring Industrial Raspberry Pi 3 platform (https://forum.hilscher.com/forum-1.html) +--- Forum: Software (https://forum.hilscher.com/forum-5.html) +--- Thread: Bluetooth (/thread-184.html) Pages:
1
2
|
Bluetooth - Jonas.Sellmann@outlook.de - April-19th-2018 Hello, I try to use bluetooth functions in a debian container. For this I used the Image hilschernetpi/netpi-bluetooth and followed the instructions described on this site: https://github.com/Hilscher/netPI-bluetooth/blob/master/README.md. After I have started the container I can use bluetoothctl, but it doesn't find any devices. With a normal raspberry pi and bluetoothctl I can find all bluetooth devices. Any ideas? Thanks in advance, Jonas Answer - PBulach - April-19th-2018 Hello, I saw on my device the issue that the bluetooth could not used from a container which starts at device start up. If I restart the container, it could use the bluetooth device. I used the hilschernetpi/netpi-bluetooth:latest Image for my container. In the Logs from the Container I saw the following messages: After startup: 2018-04-19T14:53:50.847929090Z Initialization timed out. 2018-04-19T14:53:50.938205340Z Can't get device info: No such device After restart from the container: 2018-04-19T14:55:57.756145761Z Can't get device info: No such device 2018-04-19T14:56:09.631514767Z Patch not found, continue anyway Maybe it is on your side the same issue? Is it possible to get that working directly at power up? Best Regards Patrick Bulach Answer - Armin@netPI - April-19th-2018 Well this needs investigation. The bluetooth container is one of the oldest container we ever made. I had a user Thomas using it intensively and providing valueable information in november 2017 here https://www.netiot.com/de/forum/?tx_typo3forum_pi1%5Btopic%5D=30&tx_typo3forum_pi1%5Baction%5D=show&tx_typo3forum_pi1%5Bcontroller%5D=Topic&cHash=83d0e92682f62f6cff171c10f134f8ae He got everything work with bluez 5.47 and his arm watch device. But since all our containers are built automatically based on every update cycle of the os tree used (debian:jessie in case of the bluetooth container) I cannot exclude that something has changed in the os tree meanwhile that leads to a malfunction maybe. Basically there are no known issues. Important is to set privileged mode to "on" and the network to "host" state when the containers is started. Else bluetooth in a container does not work in all cases. Since netPI shares Wifi and bluetooth in one antenna and chip there shouldn't be a hardware issue. Answer - PBulach - April-19th-2018 Hello Armin, for my issue the bluetooth is working after a restart from a container. Do you have there some hint how it could also work at system start up? Some workaround idea to restart the container somehow automatically after startup? Best Regards Patrick Bulach Answer - Armin@netPI - April-19th-2018 Hi Patrick, to be honest this would be the very first time I heard of that a container and its applications installed do not start right after a system boot. This would raise Docker to question if there would be such a basic error. If you dig deeper into Docker technology you see that all application threads and daemons started in a container are 100% threads in the host linux. So there are no differences who is starting them and I really would wonder why this would happen now with the bluetooth daemon. I have not tested it myself yet on a netPI. What I can say is that the provided example bluetooth container runs fine on a standard raspberry Pi 3 I have right in front of me. So there is no software problem at all. Also netPI is 100% the same circuit as an original Pi 3, so it can be a hardware issue. Since the bluetooth container allows you to login from remote using putty what happens in your container when it didn't activate bluetooth and you login with root:root and call "bluetoothctl" in in the shell "scan on". Does it start to scan and output the found bluetooth devices on your console? Give me time tomorrow to make checks with a netPI and then we will see. Answer - Armin@netPI - April-19th-2018 Restarting a running container cannot be triggered from a software that is running in a container. There is no access to this interface possible. So my answer is: bluetooth must run from the beginning and I will tell you results tomorrow after I have investigated this issue on my netPI. Answer - PBulach - April-19th-2018 Hello Armin, My experience is from the netPi. I could show it to you very fast with e.g. teamviewer. After system restart it will not find the device on the container. After container restart it will find it. (as mentioned also before) I hope that we will find a way to get that working, or we get a problem on our project. (It is not a solution to restart container on ever device by hand after a power loss. I have not found a way to controle the docker without the portainer.io - that it could be maybe controlled from a server.) Best Regards Patrick Bulach Answer - Armin@netPI - April-19th-2018 Well Patrick, after watching the source code again after 6 month I am pretty sure that I know what the problem comes from. When raspberry circuitry is powered then of course the main CPU starts operating and is booting from SD card. But what you must know is that there is a second chip responsible for bluetooth called BCM43xx processor. This chip does not have any firmware after a power on. If now the container is started the first time when netPI is fresh then the containers task is to load the bluetooth firmware into the chip using the command "hciattach /dev/ttyAMA0 bcm43xx 921600 noflow" located in the entrypoint.sh file. My interpretation is that the hciattach command returns after having loaded the bluetooth firmware and the script continues to run ... and failes because there is no script code waiting for the bluetooth chip to start the firmware. And later if you start the container a second time then the bluetooth chip is already loaded and needs no firmware and everything works fine. So the task is now to find a parameter in the hciattach command to wait for chip initialization or to use any other command to make sure the bluetooth chip is ready. Armin Answer - Armin@netPI - April-20th-2018 I investigated the potential problem but I am not able to reproduce any malfunction. Just to synchronize ... I am using the latest netPI software V1.1.2.0 you can download from the web site's download section. So what have I done? I started the container hilschernetpi/netpi-bluetooth:latest with network = host and privileged mode = on and device = /dev/ttyAMA0 mapped. Then I shutdown the device and repowered it, so that the it comes up from a fresh boot. When Docker was ready back I watched the embedded log entry in the Docker web GUI. You can get to this log window yourself, if you click the container name in the running container list and then click as next to "!Logs". There I can see the following starting ssh ... starting dbus ... Starting OpenBSD Secure Shell server: sshdStarting system message bus: dbus. init Set Controller UART speed to 921600 bit/s Flash firmware /etc/firmware/BCM43430A1.hcd Set Controller UART speed to 921600 bit/s Device setup complete This log is the output of a console if you would run the container on a standard Raspberry Pi 3 and very helpful, cause netPI has no console due to the web based handling. As next there is another click you can do once you clicked on the container name in the container list. It is the option ">_ Console". With this option you can immediately jump into the container and run a web based console. In this console I did call bluetoothctl and a scan on on after the other and the device immediately starts scanning: root@NTB827EB237AC1:/# bluetoothctl [NEW] Controller B8:27:EB:890:6B BlueZ 5.47 [default] [bluetooth]# scan on [NEW] Device 7B:0F:C7:3A:06:AF 7B-0F-C7-3A-06-AF [NEW] Device 00:1A:E8:2F:75:38 OpenStage 00:1A:E8:2F:75:38 [NEW] Device 58:3D:19:81:CC:12 58-3D-19-81-CC-12 Agent registered Discovery started [CHG] Device C8:F7:33:C6:B0:A0 RSSI: -70 [bluetooth]# So I am sorry, I am not able to reproduce any problem. Answer - PBulach - April-20th-2018 Hello Armin, thanks for your response. We updated the netPI (it was 1.1.0.0 before) and load the container again, now it look likes to work directly after power up. Thank you and a nice weekend. |