• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[SOLVED] Bluetooth Functions
#1
Hello,

I have two different questions to the bluetooth functions:

1: Is there an option to get the bluetooth module of the host system, without restarting the netPI?

2: Do you know how many devices can be connected simultaneously to a container in the netPI?


Thanks in advance,

Jonas
  Reply
#2
Hello Jonas,

1.) I don't understand "getting the bluetooth of the host without restarting netPI"? What exactly do you mean? At least you have to load the bluetooth container into netPI at least once, correct? And then you tell it is necessary to restart netPI in this case? Why should this be necessary? What is not working if you do not restart netPI?

2.) If bluetooth is running in a container the bluetooth operation is no restricted by any instance. So the same amount of bluetooth device will run as if you are working with bluetooth on a standard Raspberry Pi

Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#3
(September-14th-2018, 10:55 AM)Armin@netPI Wrote: Hello Jonas,

1.) I don't understand "getting the bluetooth of the host without restarting netPI"? What exactly do you mean? At least you have to load the bluetooth container into netPI at least once, correct? And then you tell it is necessary to restart netPI in this case? Why should this be necessary? What is not working if you do not restart netPI?

2.) If bluetooth is running in a container the bluetooth operation is no restricted by any instance. So the same amount of bluetooth device will run as if you are working with bluetooth on a standard Raspberry Pi

Armin

Hello Armin,

I build an own python container and added the configurations from the example bluetooth container you can pull from netpi's docker hub. In an old post you described, that you have to reboot the device, so that it comes from a fresh boot:
     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

(September-14th-2018, 10:55 AM)Armin@netPI Wrote: Hello Jonas,

1.) I don't understand "getting the bluetooth of the host without restarting netPI"? What exactly do you mean? At least you have to load the bluetooth container into netPI at least once, correct? And then you tell it is necessary to restart netPI in this case? Why should this be necessary? What is not working if you do not restart netPI?

2.) If bluetooth is running in a container the bluetooth operation is no restricted by any instance. So the same amount of bluetooth device will run as if you are working with bluetooth on a standard Raspberry Pi

Armin

Hello Armin,

I build an own python container and added the configurations from the example bluetooth container you can pull from netpi's docker hub. In an old post you described, that you have to reboot the device, so that it comes from a fresh boot:

 "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"

When I only restart the container there comes up the message "No such device" and when I completely restart the netPi the message "Device setup complete" comes up.
  Reply
#4
Well Jonas, I tried my best to get the container running bluetooth fine after a software restart. But I failed. I remember the time I created this container and failing already. And things did not improve ...

Whenever the command

hciattach /dev/ttyAMA0 bcm43xx 921600 noflow

is called again - means loading the bluetooth chip with firmware and attach it to the bluez stack - it will fail. It comes back with "Initialization time out".

As a consequence the restart of the container will not get managed to bring the bluez stack up and running again.

This is not a specific netPI problem and happens on a standard Raspberry Pi 3 too. It seems that within the command the function

static int init_uart(char *dev, struct uart_t *u, int send_break, int raw)

fails to get in touch with the BCM43 chip ... but the reason I don't know. If you goole the term "Initialization time out" you find several discussions having the same problem.

So I am sorry I can't help any futher. Maybe others know better.

Thx
Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#5
I investigated the problem and finally I found a solution: resetting the BCM chip physically before initializing the firmware is the key point

This is enabled by a tool called vcmailbox coming from Raspbian userland space.

The usage is the following: 

$ /opt/vc/bin/vcmailbox 0x38041 8 8 128 0

$ sleep 1
$ /opt/vc/bin/vcmailbox 0x38041 8 8 128 1
$ sleep 1

after that the standard command

$ hciattach /dev/ttyAMA0 bcm43xx 921600 noflow

can be called as usual and will succeed in all cases seen so far.

The vcmailbox binary can be received from here. It needs access to the device /dev/vcio. So make sure you expose it when you start your updated container.

Our bluetooth reference implementation container has been updated already.

Thx
Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)