BlueHeron - A new Bluetooth LE library

Your Libraries & OS Mentoring Libraries
, ,
1

BlueHeron is a new Bluetooth LE (BLE) library that’s focused on communicating directly with Bluetooth modules on embedded devices like those running Nerves and on desktops and laptops. It uses the Bluetooth HCI protocol and currently supports USB Bluetooth dongles and UART-connected Bluetooth modules.

What can you do with Bluetooth LE? A lot!

We’re focused on using BLE to interact with Bluetooth-enabled devices, implement beacons, and let smartphones directly communicate with Nerves devices.

This is the beginning and the library supports a fraction of this. We do have quite a bit of the underlying infrastructure in place. Our current focus is controlling a Bluetooth light bulb since it’s inexpensive, widely available, and has a simple interface that’s representative of many Bluetooth devices.

The good news is that there is a lot of commonality in the code used to control the bulb and the other use cases. Please check out the GitHub repository for more information, the rationale for why we’re doing this, and for examples.

If there’s a particular use case that you’re interested in, we’d love your help. We chat in real-time on the #nerves-bluetooth channel on the Elixir slack.

In particular, we are very interested in examples and HCI traces of working setups to emulate.

The library doesn’t support all Bluetooth hardware yet. Please try to find ways of using the same hardware as us. While broad BT hardware support is possible and a goal, we’re focused on implementing BLE use cases on current working hardware. That means that if your Bluetooth module doesn’t work, we’re probably not going to be able to help much other than ask you to find your hardware vendor’s BT firmware .hcd file and debug from there.

We’ll be posting updates to this thread.

Hopefully a few of you can join us on this adventure.

34 Likes
2

Here are a few examples i’ve managed to create with this library so far. They are both available on the repo!

1 Like
3

Hi, do you have a document to install it from scratch? I have Raspberry Pi 4 and need to work with Bluetooth.
I want to connect to OBD (which is a cable to connect Bluetooth) to get a car info.

1 Like
4

I’m trying to set up a development environment to study how blue_heron works and maybe work on some open issues/features. Inspired by this gist from @fhunleth I figured that it should be possible to bridge the uart device from the rpi to my local development machine. This setup relies on a proper setup of usb-gadget mode and socat to create a bridge. It’s quite neat, and sounds like a good setup for fast feedback when developing.

Unfortunately I don’t own an rpi0, but instead have rpi0-2w. I thought it would be a good exercise to get comfortable with buildroot and embedded linux to create a similar setup but for the newer rpi0-2w. But after a few days of trying to figure out the correct buildroot options and kernel settings I must admit that I can’t find the magic combination. I know it must be possible, since the nerves-livebook images runs fine on my rpi0-2w, with the blue_heron examples.

My strategy was to start from the vanilla raspberrypizero2w defconfig in the buildroot sources. I managed to add usb-gadget support and connect through usb. But whatever I change in the rpi specific files (e.g. config.txt and cmdline.txt), I can’t make the bluetooth device appear. I’ve read up on the miniuart-bt overlay. Toggeling that overlay works as expected with regards to the serial device that’s mapped to the GPIO pins (so either /dev/ttyS0 or /dev/ttyAMA0 is available). But I never find both devices at the same time. The bluetooth one is always missing.

One dmesg message that appears consistently is:

[ 2.992154] 3f215040.serial: ttyS0 at MMIO 0x3f215040 (irq = 86, base_baud = 31250000) is a 16550
[ 2.996671] serial serial0: tty port ttyS0 registered
[ 2.999585] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
[ 3.002049] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
[ 3.005552] mmc-bcm2835 3f300000.mmcnr: mmc_debug:0 mmc_debug2:0
[ 3.007846] mmc-bcm2835 3f300000.mmcnr: DMA channel allocated
[ 3.039163] sdhost: log_buf @ 03e6aa8d (d5911000)
[ 3.090196] mmc0: sdhost-bcm2835 loaded - DMA enabled (>1)
[ 3.093425] uart-pl011 3f201000.serial: there is not valid maps for state default
[ 3.096029] uart-pl011 3f201000.serial: cts_event_workaround enabled

In config.txt I have enable_uart=1. I’ve futzed with dtoverlay=miniuart-bt (I also have dtoverlay=dwc2 enabled for the usb-gadget mode). I also tried core_freq=250 because that seemed to have enabled bluetooth on the rpi3a nerves system before. But IMHO I think only enable_uart=1 is required to make the pi run on a fixed frequency to make miniuart usable (apparently miniuart is coupled to the GPU frequency).

Other buildroot options that I’ve tried are:

BR2_PACKAGE_BRCMFMAC_SDIO_FIRMWARE_RPI=y
BR2_PACKAGE_BRCMFMAC_SDIO_FIRMWARE_RPI_BT=y

Kernel options paired with that firmware:

CONFIG_SERIAL_8250_BCM2835AUX=y
CONFIG_BT_HCIUART=y
CONFIG_BT_HCIUART_BCM=y

The above two sets of options were just some guesses based on LLM suggestions (it’s not like I knew what I was doing :slight_smile: ). But still no cigar.

There is a 32 bit and a 64 bit version of the raspberrypizero2w defconfig in the buildroot boards. But I only could get the 32 bit up and running with usb-gadget mode on. If the 64 bit one is key here, I’d love to know, because then I can try to get that running with a bit more effort.

My hypothesis is that I’m lacking the correct kernel options to enable the bluetooth uart device. Something chipset specific. But I’m surprised that bluetooth isn’t working on the vanilla defconfig shipped with buildroot. But that’s probably a wrong expectation from my part.

Anyway. A lot of linux kernel compiling last few days :smiley:. How do you develop for blue_heron? Am I right to pursue this setup? Or are there other ways to have a comfortable feedback loop for this?

Another strategy I can come up with is using the buildroot that’s underlying the official nerves systems (which one then, there seem to be two different ones suitable for rpi0-2w). But I haven’t figured yet out how that would work.

If I get it to work, I can submit a guide to save other developers having to figure this out in the future.

5

I can’t help with the other parts, but I can help with 32-bit vs. 64-bit. If 32-bit is working for you, then don’t worry at all about 64-bit until the end. I think it will just work on nerves_system_rpi0_2 modulo any kernel option updates you find.

The only other hint I have is something I discussed with Connor a while back which didn’t seem to work out, but I don’t know why. Take this with a grain of salt since I don’t feel like I’m an expert on this. My understanding about Bluetooth support is that you almost always have to update the firmware on the module since it’s either old or missing. I think BlueHeron got lucky on some Raspberry Pi’s since the Bluetooth firmware was good enough and didn’t need an update. The BlueHeron backend that everyone uses connects directly to the modules via UART, so it’s responsible for the firmware updates. If BlueHeron had a backend that went through the Linux kernel’s HCI drivers then the kernel could do the firmware updates. At one time, I think the kernel was lacking in this area, but that seems like years ago and is hopefully totally solved by now. I don’t remember the Linux Bluetooth driver interface being well-documented so code spelunking was needed. Since the kernel’s HCI interface should be the same on devices, if I were doing this, I’d start with one of the Raspberry Pi’s with more interfaces (like a Pi 4 or 5), then I’d probably try Buildroot first and play around with strace and hciutil to see what happens and orient myself with where to look in code. If I had trouble there, I’d install Raspberry Pi OS and uninstall/disable bluez.

3 Likes