Action Item #252
closedReview requirements for BLE
100%
Description
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.
- Upgrade to latest kernel at github.com/raspberrypi (see RM #176)
- Bump Bluez-utils to 5.14 in Buildroot.
- Get a Bluetooth 4.0 dongle from Seeedstudio
- Build app based "gatttool" in BlueZ/attrib and referencing
*Update: 2015/07/18: *
bluez-tools repo has moved from gitorious to github: https://github.com/khvzak/bluez-tools
Related issues
Updated by Hammel over 10 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.
Updated by Hammel over 10 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.
Updated by Hammel over 10 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.
Updated by Hammel almost 10 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.
Updated by Hammel almost 10 years ago
- Severity changed from 03 - Medium to 01 - Critical
Updated by Hammel over 9 years ago
- % Done changed from 10 to 20
- http://unix.stackexchange.com/questions/96693/connect-to-a-bluetooth-device-via-terminal
- http://www.lightofdawn.org/blog/?viewDetailed=00031
- http://www.lightofdawn.org/blog/?viewDetailed=00032
- http://wiki.gentoo.org/wiki/Bluetooth_Headset
- https://wiki.gentoo.org/wiki/ALSA
- http://www.linuxfromscratch.org/hints/downloads/files/OLD/alsa.txt
- http://superuser.com/questions/465472/how-to-connect-bluetooth-headset-via-command-line-on-ubuntu-12-04
- https://help.ubuntu.com/community/BluetoothSetup
- https://wiki.archlinux.org/index.php/Bluetooth_headset
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756454
The BLE device I have seems to work with these tools, at least on my laptop. If not, I can order a device that has a CSR8510 chipset since these are known to work with the RPi.
Note: PiBox is now at 3.14.27+ and bluez 4.01 is enabled. I just need to package the bluez-tools to try this out on the target.
Updated by Hammel over 9 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.
Updated by Hammel over 9 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.
Updated by Hammel over 9 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.
Updated by Hammel over 9 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: http://wiki.beyondlogic.org/index.php?title=Cross_Compiling_BlueZ_Bluetooth_tools_for_ARM
Updated by Hammel over 9 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.
Updated by Hammel over 9 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.
Updated by Hammel over 9 years ago
Created upstream repo @ GitLab.com and pushed.
Package now just needs to be tested to see if it works.
Updated by Hammel over 9 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 UP RUNNING PSCAN 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.
Updated by Hammel about 9 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).
Links¶
- How to run BlueZ
- Archlinux Bluetooth
- BluetoothUser/a2dp
- Bluetooth on Raspberry - Audio Streaming
- How to connect to Bluetooth headset/soundbar/speaker
- Looks like a definitive example using bluez-tools
- bt-audio man page
- Bluetooth for Programmers
- This discusses programming using libbluetooth, which is installed in PiBox.
- Bluetooth Headset
- 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.
- ALSA on Gentoo Wiki
- 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.
Notes¶
- 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.
Updated by Hammel about 9 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.- http://www.linuxfromscratch.org/blfs/view/svn/multimedia/alsa-lib.html
- http://www.linuxfromscratch.org/blfs/view/svn/multimedia/alsa-utils.html
- http://www.alsa-project.org/main/index.php/Asoundrc
- There is an alsa bootscript in the LFS bootscripts package.
- Here is an alternate setup for alsa over bluetooth.
- Instructable for setting it up on Raspbian (some alsa commands that might be useful)
- Some helpful tips on the Archlinux forums
Updated by Hammel about 9 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" MAC=00:22:37:10:EE:BD # Load modules modprobe btusb # Start bluetooth daemon # Starts itself as a daemon bluetooth # 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 [General] AutoConnect=true Enable=Sink,Source,Socket Disable=Media SCORouting=PCM # 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
Updated by Hammel about 9 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"http://intensecode.blogspot.com/2013/10/tutorial-vlc-with-hardware-acceleration.html might work as an alternative but it may require a lot of updates to the base platform.
Updated by Hammel about 9 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:- Integrate LFS bluetooth init script to base platform.
- 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.
Updated by Hammel about 9 years ago
init scripts are installed. They need to be tested with a new image on SD.
Updated by Hammel about 9 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.
Updated by Hammel about 9 years ago
Committed and pushed.
Basic bluetooth support is available now. Future bluetooth requirements will be tracked separately.
Closing issue.
Updated by Hammel about 9 years ago
- Status changed from In Progress to Closed
- % Done changed from 90 to 100