2

I've tested this over various Raspberry Pi's(Pi Zero and Pi 2) and different versions of Raspbian lite(Latest to oldest version from 2015) and different versions of BlueZ (5.23, 5.43, 5.49). I have also tested this on multiple cheap CSR 4 USB Bluetooth devices as well as an ancient USB Bluetooth 2.1 module.

The issue is that when I change the Bluetooth class to 0x20041C (for a project of turning the Pi into a Bluetooth speaker), it always switches to 0x00041C and ignores my suggested Service Class part of the class identifier.

What I've been doing for changing the Bluetooth class is as so: I add Class = 0x20041C to both the file /etc/bluetooth/main.conf as well as the config specific to my Bluetooth device /var/lib/bluetooth/<MACADDRESS OF BLUETOOTH>/config. After that I restart the Pi to update the Bluetooth changes, and when I run hciconfig -a it shows the class for HCI0 (my USB bluetooth device) as 0x00041C. Even running

sudo hciconfig hci0 class 0x20041C

temporarily changes it, but once I restart the bluetooth service the Class just goes right back to 0x00041C.

As far as I'm aware there isn't anything that I am doing differently than all of the other countless tutorials online for working with Bluetooth on the Pi (as well as making bluetooth speakers with it) and I don't understand why my case is any different and causes this weirdly simple error.

2 Answers 2

1

/var/lib/bluetooth/settings is going to be volatile. If you change it there, it will be reverted back to original configuration.

In your /etc/systemd/system/ you should see a dbus-org.bluez.service which is symlinked and aliased from the /lib/system/system/bluetooth.service file.

If the service type is dbus, then you might want to configure it in there.

0

The service class appears to be generated based on what protocols are available on the device - ie, you need to run something that provides the A2DP protocol (pulseaudio-module-bluetooth or bluealsa) and the service class will be updated after you restart the bluetooth service. hciconfig can change the class presented, but not the underlying protocols, so the connection will fail when the device you're connecting can't get the appropriate protocol.

If you're using bluealsa (which is included already in the Raspbian full w/ recommended software image), note that its default configuration is to run as an audio source (audio out to bluetooth speakers, etc), and if you want to run it as an audio sink (audio in from a phone, etc) you have to edit /lib/systemd/system/bluealsa.service and change the ExecStart line to ExecStart=/usr/bin/bluealsa --profile=a2dp-sink (see this github issue for details). The Pulseaudio version may need similar configuration.

I spent about three hours sorting this out last night, so hopefully this helps the next person to come along :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.