Action Item #252

Review requirements for BLE

Added by Hammel almost 8 years ago. Updated about 6 years ago.

Status:ClosedStart date:25 Nov 2013
Priority:ImmediateDue date:
Assignee:Hammel% Done:


Category:06 - Hardware
Target version:0.11.0
Severity:01 - Critical


BLE is Bluetooth Low Energy, which is what the TI SensorTag uses.
BLE is part of Bluetooth 4.0.
Bluetooth 4.0 requires kernel 3.5 or later.
BlueZ 4.101 is the default in Buildroot 2013.11 (current PiBox version) but 5.14 is latest Bluez user space release.
PiBox is currently using kernel 3.2.27.


*Update: 2015/07/18: *
bluez-tools repo has moved from gitorious to github:

Related issues

Duplicated by PiBox - Feature #435: Add Bluetooth audio source Closed 22 Mar 2015

Associated revisions

Revision 037d7c5a
Added by Hammel over 6 years ago

RM #252: Initial import of BlueZ Tools packaging metabuild.

Revision 6c819b74
Added by Hammel about 6 years ago

RM #252: Switch repos for bluez-tools to github. Change package name to bluez-tools.

Revision 27769f6a
Added by Hammel about 6 years ago

RM #252: Integrate build of BlueZ 5 version. The default is the 4.x version. Setting B5=1 bulds the 5 version. PiBox defaults to the 4.x version for now.

Revision b1348883
Added by Hammel about 6 years ago

RM #252: Added bluetooth and alsa init scripts. Default configurations will need to be created manually by apps.


#1 Updated by Hammel over 7 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

RPI git has a 3.6.y branch. However, usbfs was deprecated in that branch so usb devices don't get identified properly on boot by mdev. So RM #273 needs to be addressed first before this issue can be investigated further.

#2 Updated by Hammel over 7 years ago

  • Description updated (diff)

#3 Updated by Hammel over 7 years ago

  • Target version changed from 2.0 - Harkonnen to 0.9.0

The move to 3.10.y means BLE should be supported by the kernel. So that means I need to make a list of tasks to get BLE working with the TISensorTag and schedule them for inclusion with the PiBox Media Server v1.0 release.

#4 Updated by Hammel over 7 years ago

  • Priority changed from High to Normal
  • Target version changed from 0.9.0 to 0.10.0

Additional work on this is being pushed to 0.10.0 so I can get the media specific stuff completed in time for camping season.

#5 Updated by Hammel almost 7 years ago

  • Target version changed from 0.10.0 to 0.11.0

Bumping to 0.11 to get 0.10 release out the door.

#6 Updated by Hammel almost 7 years ago

  • Severity changed from 03 - Medium to 01 - Critical

#7 Updated by Hammel over 6 years ago

  • Priority changed from Normal to Immediate

#8 Updated by Hammel over 6 years ago

  • % Done changed from 10 to 20

#9 Updated by Hammel over 6 years ago

  • % Done changed from 20 to 30

bluez-tools requires an update to gobject (re: glib) to 2.38 or later. It's currently at 2.36.

Current buildroot is way past this so it might be time to consider bumping buildroot to a newer version. Alternatively I could apply a patch to libglib2 to bump the version. Note that bluez-tools is not in current buildroot so I'd still have to make the package anyway.

Either way it means rebuilding the rootfs to support bluez-tools.

#10 Updated by Hammel over 6 years ago

I tested Buildroot 2015.02. It builds fine with the attached minor patch (to PiBox configs, not to Buildroot). I then created a bluez-tools metabuild. I'm not sure if that works yet, however. I got distracted by having to migrate from Gitorious to GitLab. Now that the migration is complete I can get back to continue testing the bluez-tools build.

#11 Updated by Hammel over 6 years ago

  • % Done changed from 30 to 40

Buildroot has been bumped and tested in my secondary sandbox. Changes committed and pushed upstream (to gitlab).

Apps are being tested against this. Should be okay.

Then I can go back to testing BLE builds.

#12 Updated by Hammel over 6 years ago

Cross compile seems to be failing. I'm getting errors that the compiler won't build an executable.

Here is some info on cross compiling bluez:

#13 Updated by Hammel over 6 years ago

  • % Done changed from 40 to 50

Scratch that. I was just pointing SD to the staging tree when it should have been pointed at the target tree.

Build completes. Ready to try packaging and using. Need to create a repo for it upstream first.

#14 Updated by Hammel over 6 years ago

  • % Done changed from 50 to 70

The bluez tree is ready for checkin. Use "bluez" cdtools function to find it.

The tree builds an opkg that still needs to be tested on target platform.

#15 Updated by Hammel over 6 years ago

Created upstream repo @ and pushed.

Package now just needs to be tested to see if it works.

#16 Updated by Hammel about 6 years ago

hciconfig shows the device if I inserted it after starting bluetoothd:

hci0:   Type: BR/EDR  Bus: USB
        BD Address: 00:1A:7D:DA:71:13  ACL MTU: 310:10  SCO MTU: 64:8
        RX bytes:606 acl:0 sco:0 events:36 errors:0
        TX bytes:939 acl:0 sco:0 commands:36 errors:0

I haven't had time to try anything else yet. I need to review some of the links in this issue first.

#17 Updated by Hammel about 6 years ago

General probing

  • load the bt modules: modprobe btusb
  • Run hciconfig to see if the device is working:
  • Verify local bt is working: hciconfig
    hci0:   Type: BR/EDR  Bus: USB
            BD Address: 00:1A:7D:DA:71:13  ACL MTU: 310:10  SCO MTU: 64:8
            UP RUNNING PSCAN 
            RX bytes:1158 acl:0 sco:0 events:63 errors:0
            TX bytes:1050 acl:0 sco:0 commands:63 errors:0
  • Look for other devices: hcitool scan
    • Make bluetooth device visible to world (on phone, see bluetooth settings)
    • Run this command, get back something like this:
      # hcitool scan
      Scanning ...
              64:89:9A:F2:4B:58       LG Volt
  • Ping the device: l2ping 64:89:9A:F2:4B:58
    # l2ping 64:89:9A:F2:4B:58
    Ping: 64:89:9A:F2:4B:58 from 00:1A:7D:DA:71:13 (data size 44) ...
    0 bytes from 64:89:9A:F2:4B:58 id 0 time 12.57ms
  • Browse services: sdptool browse 64:89:9A:F2:4B:58
    • Returns lots of info

This can be used with bt-obex for file transfer. Now I need to find out how to setup audio.

Pairing for Audio

It appears that to pair the RPi with a bt audio output device (Beat Pill, for example), all that is necessary is to specify the address, as in this example:
  • bt-audio -c 64:89:9A:F2:4B:58
    I haven't tried this yet, however. Bluetooth on Raspberry has some additional info though it appears to use older versions of the bluez tools (bluetoot-agent instead of bt-agent).


  1. How to run BlueZ
  2. Archlinux Bluetooth
  3. BluetoothUser/a2dp
  4. Bluetooth on Raspberry - Audio Streaming
  5. How to connect to Bluetooth headset/soundbar/speaker
    1. Looks like a definitive example using bluez-tools
  6. bt-audio man page
  7. Bluetooth for Programmers
    1. This discusses programming using libbluetooth, which is installed in PiBox.
  8. Bluetooth Headset
    1. This says that BlueZ5 is not supported by Alsa, only PulseAudio. So I'll have to work with BlueZ 4.x to skip PulseAudio. # PiBox does not currently have an /etc/bluetooth/audio.conf file. There is an example of one on kepler. Question: why isn't there a default audio.conf? It came from bluez-utils package on kepler. The buildroot build of bluez-utils has a sample audio/audio.conf. But it doesn't appear to get copied into the output/target tree. However, see RM #435. This file may need to be generated by the UI/cli tool.
    2. ALSA on Gentoo Wiki
  9. PiBox also needs to configure an asoundrc file. See also the lightofdawn discussion, which is the best discussion of using BlueZ without pulseaudio (he's already "been down this rabbit hole"). He has additional discussion related to this and a2dp. Also, from RM #435, it seems we can use both the audio.conf and the asoundrc file with the latter generated by the UI/cli but the former static.


  • GATT support is not enabled in Buildroot currently
  • bluez-utils in Buildroot is BlueZ 4.101. BlueZ5 was added as a new package in Auguest 2014. However, since I already had bluez-utils enabled (for 4.x) I didn't see the new BlueZ5 package. So now I need to try that. Note that there are no patches against it that I would want since the Buildroot 2015.02 release.

#18 Updated by Hammel about 6 years ago

  • Description updated (diff)

#19 Updated by Hammel about 6 years ago

Talked with Will (who did a lot of bluetooth stuff at his last job) and found that the dongle I'm using (from ModMyPi) is a Bluetooth 4.0 model. That means it supports both Bluetooth Classic and Bluetooth Low Energy. So it should work in my case. The fact that the JBL speaker beeps when I try to connect seems to verify that connection works. So this doesn't look like a Bluetooth problem.

I think this might be an ALSA issue. See using ALSA on Raspberry Pi article for help with ALSA.

#20 Updated by Hammel about 6 years ago

  • % Done changed from 70 to 80

Testing with the following got audio to play through the bluetooth speaker. However, omxplayer does not play through it.

# JBL micro speaker
DEVNAME="JBL Micro Wireless" 

# Load modules
modprobe btusb

# Start bluetooth daemon
# Starts itself as a daemon

# Pair with device
# Only need to do this once
bt-device -c $MAC

# Verify it's paired
bt-device -l

# Configure audio to device
# Do this every time the device turns on.
bt-audio -c $MAC

# Set as trusted
bt-device --set "$DEVNAME" trusted 1

# View config
bt-device -i "$DEVNAME" 

# Config file: /etc/bluetooth/audio.conf

# Config file: /etc/asound.conf
pcm.!default {
    type bluetooth
    device "00:22:37:10:EE:BD" #MAC address of remote device
    profile "auto" 

# Command to test audio output
# Default ALSA output it bluetooth based on asound.conf settings
aplay /usr/share/sounds/alsa/Rear_Right.wav

#21 Updated by Hammel about 6 years ago

Ugh. omxplayer doesn't support Alsa.

I'm hoping this is old info. If not, I'll have to find a hardware analog-to-bluetooth converter board to stuff into the player box.

Update: It's not old info. To use omxplayer, I'd have to add an external bluetooth transmitter.

"VLC" might work as an alternative but it may require a lot of updates to the base platform.

#22 Updated by Hammel about 6 years ago

This issue will no longer track audio playback over bluetooth. I've proven the bluetooth config will work for that. It's just omxplayer that doesn't support it.

So this issue will track getting bluetooth configured properly irrespective of whether the audio output from the video player is working. This is to support other bluetooth devices, such as input and IoT devices.

The things that need to happen:
  1. Integrate LFS bluetooth init script to base platform.
  2. Integrate LFS ALSA init script to base platform.

That's it for now. A front end GUI will have to be developed later, but I'll need a use case for it other than video player audio output.

#23 Updated by Hammel about 6 years ago

init scripts are installed. They need to be tested with a new image on SD.

#24 Updated by Hammel about 6 years ago

  • % Done changed from 80 to 90

Tested. They seem to be working. I will check them in, push and then close this issue.

Note that it only works if you
  • run bt-device to connect
  • run bt-audio to setup audio
  • Configure /etc/bluetooth/audio.conf
  • Configure /etc/asound.conf

The /etc/bluetooth/audio.conf can be set once though it may need additional configurations to support both bluetooth and non-bluetooth configurations.

The /etc/asound.conf has to be updated with every device it connects to. And it's not clear how to connect to multiple devices this way.

#25 Updated by Hammel about 6 years ago

Committed and pushed.

Basic bluetooth support is available now. Future bluetooth requirements will be tracked separately.

Closing issue.

#26 Updated by Hammel about 6 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 90 to 100

Also available in: Atom PDF