Bluetooth LE on a Pi3 running Raspbian - How to get it working

[WayneKeenan]

Prior to the May'16 Raspbian release with the 4.4 Kernel (which needs the steps below applied) my last 'known good' versions were:

https://downloads.raspberrypi.org/raspbian/images/raspbian-2016-02-29/2016-02-26-raspbian-jessie.zip
sudo rpi-update 692dde0c1586f7310301379a502b9680d0c104fd
BlueZ: 5.39

To get the GATT advertising working on the latest Raspian I had to make a few tweaks involving:

• Installing and patching Bluez 5.39 with a set of Pi kernel maintainers patches for the Pi3
• config.txt settings
• Running the bluezero examples with sudo (which I didn't think was necessary before)

Note: This will let the example work and 'hciconfig' shows a 'real' MAC address as opposed to an address of AA:AA:AA:AA:AA,which is a symptom of the hciattach issue. However, running show in bluetootctrl shows No default controller available - so something is still not quite right.

Patch BlueZ source

Obtain the BlueZ source, I've tested with 5.39.

cd bluez-5.39
wget https://gist.github.com/pelwell/c8230c48ea24698527cd/archive/3b07a1eb296862da889609a84f8e10b299b7442d.zip
unzip 3b07a1eb296862da889609a84f8e10b299b7442d.zip
git apply  -v c8230c48ea24698527cd-3b07a1eb296862da889609a84f8e10b299b7442d/*

You should see:

Checking patch tools/hciattach.c...
Applied patch tools/hciattach.c cleanly.
Checking patch tools/hciattach_bcm43xx.c...
Applied patch tools/hciattach_bcm43xx.c cleanly.
Checking patch tools/hciattach.c...
Applied patch tools/hciattach.c cleanly.
Checking patch tools/hciattach_bcm43xx.c...
Applied patch tools/hciattach_bcm43xx.c cleanly.

Then configure, compile and install BlueZ as per the bluezero instructions found here

config.txt

For reference, this is my entire /boot/config.txt which includes some commented out lines tried whilst investigating, things worked better without them in the end.

dtparam=audio=on
lcd_rotate=2
start_x=1
gpu_mem=128
framebuffer_width=1280
framebuffer_height=720
#core_freq=250
#enable_uart=1
#dtoverlay=pi3-miniuart-bt

[WayneKeenan]

Using sudo on the latest (May'16) Raspbian is currently required but wasn't in the previous release.

I've found a there is a DBus ACL difference between the Feb'16 and May'16 Raspbian releases.

To add the ACL setting back create a file called dbus-bluetoothgroup.patch:

--- bluetooth.conf  2016-05-26 06:58:37.013356724 +0000
+++ bluetooth_addgroup.conf 2016-05-26 06:58:59.884183163 +0000
@@ -24,6 +24,11 @@
     <allow send_interface="org.freedesktop.DBus.Properties"/>
   </policy>

+  <!-- allow users of bluetooth group to communicate -->
+  <policy group="bluetooth">
+    <allow send_destination="org.bluez"/>
+  </policy>
+
   <policy at_console="true">
     <allow send_destination="org.bluez"/>
   </policy>

Apply the patch

sudo patch -b /etc/dbus-1/system.d/bluetooth.conf < dbus-bluetoothgroup.patch

Add the current user (e.g. pi) to the bluetooth group (re-login required)

sudo usermod -G bluetooth -a $USER

[ukBaz]

This appears to have been fixed with the combination of:
Raspbian Jessie with PIXEL
Version: September 2016
Release date: 2016-09-23

And was tested along with BlueZ 5.42

[ukBaz]

After a reboot the problem seems to be back so I'm re-opening the issue

$ bluetoothctl 
[NEW] Controller AA:AA:AA:AA:AA:AA RPi3 [default]
[bluetooth]# show
Controller AA:AA:AA:AA:AA:AA
    Name: RPi3
    Alias: RPi3
    Class: 0x000000
    Powered: yes
    Discoverable: no
    Pairable: yes
    UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
    UUID: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)
    UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
    UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
    UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
    Modalias: usb:v1D6Bp0246d052A
    Discovering: no
[bluetooth]# exit
[DEL] Controller AA:AA:AA:AA:AA:AA RPi3 [default]

There is some noise up above as to exactly what steps are needed so I'll summarising the steps I took to clear the issue:

$ cd bluez-5.42/
$ wget https://gist.github.com/pelwell/c8230c48ea24698527cd/archive/3b07a1eb296862da889609a84f8e10b299b7442d.zip
$ unzip 3b07a1eb296862da889609a84f8e10b299b7442d.zip
$ git apply  -v c8230c48ea24698527cd-3b07a1eb296862da889609a84f8e10b299b7442d/*
$ make && sudo make install
$ sudo reboot

[bryanmcgrane]

Anyone know if this issue has been resolved? I'm going to try the steps above with my Pi3 and report back.

[ukBaz]

@bryanmcgrane I believe that there is no plan to send this patch upstream to BlueZ. This means that if you update BlueZ on a RPi3 then you will need to make sure you apply the patch. I believe that @pelwell knows that his gist is being used and has no plans to remove it.

[bryanmcgrane]

I was actually able to get everything running with a few modified steps. I submitted the question on Stack Overflow and answered my own question. I was able to use Bluez v5.43.

http://stackoverflow.com/questions/41351514/leadvertisingmanager1-missing-from-dbus-objectmanager-getmanagedobjects-solved/41398903#41398903

[ukBaz]

@bryanmcgrane your instructions on Stack Overflow seem very similar to ones at:
https://github.com/ukBaz/python-bluezero/blob/master/docs/install_bluez.rst

It would be interesting to know if the bcm43xx-3wire entry is in tools/hciattach.c without the applying the patch from pelwell. More details about the patch are at:
https://gist.github.com/pelwell/c8230c48ea24698527cd

I'd also be interested to see what the address of the Controller is reported as when your run bluetoothctl with your setup.

[bryanmcgrane]

Yes my process is very similar, but I ended up having to omit the configuration and make options.

bluetoothctl can't find a default adapter for me. I can check my BT address using hciconfig however which shows

hci0: Type: Primary Bus: UART BD Address: B8:27:EB:88:0E:F3 ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:4603 acl:141 sco:0 events:186 errors:0 TX bytes:5064 acl:128 sco:0 commands:102 errors:0

[pelwell]

Although we added the 3wire option, we aren't using it because we found the bcm43xx H5 support to be unreliable.

[ukBaz]

Thanks for the reply @pelwell .

However this has confused me because using an updated BlueZ version doesn't work without the patch. Do you understand why this might be?

[pelwell]

Another function of the patches is to upload the firmware at a low baud rate to make it reliable in the absence of flow control - I think that is why you need at least one of them.

[ukBaz]

Just adding a note here that there is an active discussion going on about the AA:AA:.. address issue over on the BlueZ developer mailing list:
http://marc.info/?l=linux-bluetooth&m=150289514416084&w=2

[ukBaz]

Closing this as I think the issue has been resolved with newer versions of BlueZ