Raspberry Pi 5 Bluetooth: Internal UART Routing and BLE Sensor Primer

The Raspberry Pi 5 handles Bluetooth 5.0 and BLE via the Infineon CYW43455 combo chip. Unlike older microcontrollers that expose raw RF pins, the Pi 5 routes Bluetooth traffic internally: the main BCM2712 SoC delegates I/O to the RP1 southbridge, which communicates with the CYW43455 over a dedicated high-speed UART. Understanding this physical layer is the difference between a rock-solid sensor network and a drop-prone mess.

The Physical Layer: RP1 UART and the CYW43455

Bluetooth on the Pi 5 is not a native PCIe or USB device; it is a serial peripheral. The RP1 I/O controller manages a UART HCI (Host Controller Interface) link to the radio chip. During boot, the Linux kernel initializes this link at 115,200 baud, sends a firmware patch to the CYW43455, and then ramps the UART up to 3 Mbps for high-throughput BLE and Classic Bluetooth traffic.

Protocol Fit: Classic vs. BLE vs. Alternatives

Choosing the right wireless protocol depends entirely on your payload size, power budget, and device count. The Pi 5's CYW43455 supports both Classic and BLE, but they serve fundamentally different use cases on the workbench.

The Verdict: Use BLE for remote environmental sensors (BME280, soil moisture) where the endpoint runs on a coin cell. Use Classic Bluetooth only if you are streaming audio to a DAC or connecting a legacy PS4 controller. If you need to move camera frames or high-frequency IMU data from an ESP32 to the Pi 5, abandon Bluetooth and use ESP-NOW or standard Wi-Fi UDP.

The Classic Failures: Coexistence, Baud, and Pairing

When Pi 5 Bluetooth fails, it is rarely a software bug in your Python script. It is almost always a physical layer or kernel-level collision. Here are the three most common failure modes and how to fix them.

1. 2.4GHz Wi-Fi and Bluetooth Coexistence

The CYW43455 shares a single antenna and RF front-end for both Wi-Fi and Bluetooth. If your Pi 5 is connected to a 2.4GHz Wi-Fi network and you are simultaneously pulling heavy data (like an apt update or NFS mount), the time-division multiplexing will starve the Bluetooth radio. The Fix: Always connect your Pi 5 to a 5GHz Wi-Fi network when doing heavy BLE scanning or Classic BT audio streaming. This physically separates the Wi-Fi traffic from the 2.4GHz Bluetooth band.

2. Internal UART Baud Mismatch on Boot

If you run hciconfig or bluetoothctl show and see no hci0 device, the kernel failed to upload the firmware patch to the CYW43455. This happens if the device tree overlay forces the wrong UART clock divisor, causing the 3 Mbps high-speed switch to fail. The Fix: Ensure your /boot/firmware/config.txt does not have conflicting core_freq overrides that desync the RP1 UART baud rate generator. Revert to stock clocks and reboot.

3. BLE MAC Address Randomization

Modern iOS and Android devices randomize their BLE MAC addresses to prevent tracking. If your Pi 5 Python script filters incoming sensor data by a hardcoded MAC address, it will silently drop packets the moment the phone or tablet rotates its address. The Fix: Never hardcode MAC addresses for mobile endpoints. Filter your BLE scanner by the advertised Local Name or the specific Service UUID.

Sniffing, Debugging, and a Minimal BLE Exchange

Before writing application code, you must verify the bus is actually seeing RF traffic. The BlueZ stack includes powerful sniffing tools.

Open a terminal and run the Bluetooth monitor:

sudo btmon

This dumps the raw HCI (Host Controller Interface) packets traveling between the RP1 UART and the CYW43455 chip. If you press a button on a BLE sensor and see LE Meta Event and Advertising Report lines scrolling, your physical layer is healthy. If the screen is dead, your antenna is disconnected or the kernel module crashed.

Minimal Working BLE Exchange (Python)

For application development, the Bleak library is the modern standard for Python BLE on Linux. Below is a minimal, robust scanner that looks for a specific Service UUID (e.g., a Nordic UART Service or custom environmental sensor) rather than relying on fragile MAC addresses.

Hardware Prerequisite: Ensure your Pi 5 is on 5GHz Wi-Fi and the CYW43455 metal shield is not covered by a conductive enclosure.

import asyncio
from bleak import BleakScanner

# Target the specific 128-bit UUID of your sensor's GATT service
TARGET_UUID = "0000ffe0-0000-1000-8000-00805f9b34fb"

async def scan_for_sensor():
    print("Scanning for BLE devices... (Ctrl+C to stop)")
    
    # Use the BlueZ backend explicitly for Pi 5 Linux environments
    scanner = BleakScanner(detection_callback=detection_handler, backend='bluez')
    
    await scanner.start()
    await asyncio.sleep(10.0) # Scan for 10 seconds
    await scanner.stop()

async def detection_handler(device, advertisement_data):
    # Filter by Service UUID to ignore MAC randomization
    if TARGET_UUID.lower() in [str(u).lower() for u in advertisement_data.service_uuids]:
        print(f"[HIT] Name: {device.name}")
        print(f"      RSSI: {advertisement_data.rssi} dBm")
        print(f"      MAC:  {device.address}\n")

if __name__ == "__main__":
    try:
        asyncio.run(scan_for_sensor())
    except KeyboardInterrupt:
        print("\nScan aborted.")

If the RSSI reads below -90 dBm, your sensor is at the absolute edge of the CYW43455's sensitivity. Move the Pi 5 closer, or add a dedicated external BLE gateway (like an ESP32 running ESPHome) to bridge the RF gap over Wi-Fi to the Pi.