Does the Raspberry Pi Have Bluetooth? Onboard vs UART Bus

Yes, the Raspberry Pi 3, 4, and 5 all have onboard Bluetooth. Specifically, modern boards use a wireless combo chip like the Infineon CYW43455, which handles both WiFi and Bluetooth (up to v5.0/BLE). Internally, this chip communicates with the main Broadcom SoC over a dedicated UART or SDIO bus. However, if you are asking because you want to wire an external HC-05 or HM-10 Bluetooth module to the GPIO header, you are stepping into the world of Pi physical communication buses. Understanding how UART, I2C, and SPI operate at the hardware layer is critical to avoiding fried pins and silent failures.

The Internal Hardware Reality and External GPIO Buses

When dealing with the Pi's onboard Bluetooth, the primary hardware UART (/dev/ttyAMA0) is typically hardwired to the internal combo chip. This leaves the GPIO header's UART pins (GPIO 14 and 15) mapped to the mini-UART (/dev/ttyS0) by default. The mini-UART lacks a fractional baud rate divider, meaning its clock speed fluctuates with the CPU core frequency, which can corrupt data on external Bluetooth modules unless you lock the core clock or swap the UART mappings in config.txt.

If you are bypassing the onboard radio to connect an external BLE beacon scanner or a long-range LoRa/BT bridge, you must choose the right physical bus. The decision hinges on distance, speed, and device count. UART is strictly point-to-point and ideal for streaming serial data to a Bluetooth module. I2C is best for short-distance, multi-drop sensor networks (like polling three BME280 environmental sensors). SPI is reserved for high-speed, short-distance peripherals like TFT displays or ADCs where individual chip-select routing is manageable.

Pi Communication Bus Matrix: UART, I2C, and SPI

The table below defines the physical layer constraints for the Pi's exposed GPIO buses. Note that the Raspberry Pi operates strictly at 3.3V logic. Applying 5V to any of these data lines will permanently destroy the Broadcom SoC's GPIO pad.

Classic Bus Failures and How to Sniff Them

When a bus fails to communicate, the issue is almost always at the physical layer or a configuration mismatch. Here is how to diagnose the three most common failures on the Pi.

1. UART Baud Mismatch (The Bluetooth Module Silent Failure)

The Symptom: You send AT commands to your HM-10 BLE module via minicom, but receive garbage characters or nothing at all.
The Cause: The Pi's serial console or your Python script is initialized at 115200 baud, but the external module defaults to 9600 baud out of the factory.
The Fix & Sniff: Verify the physical wiring (Pi TX to Module RX, Pi RX to Module TX). Then, open a terminal and sniff the raw bytes using minicom -b 9600 -D /dev/ttyS0. If you see legible text, your baud rate was wrong. If you see nothing, check that the Pi's serial console is disabled in raspi-config while keeping the serial port hardware enabled.

2. Missing I2C Pull-Up Resistors

The Symptom: Running i2cdetect -y 1 returns a grid of -- or, worse, locks up the bus entirely, requiring a reboot.
The Cause: I2C uses open-drain outputs. The Pi's internal pull-ups (typically 50kΩ) are far too weak to pull the bus high quickly enough at 400kHz, especially with the capacitance of jumper wires.
The Fix & Sniff: Solder or wire 4.7kΩ resistors between the 3.3V pin and both SDA (GPIO 2) and SCL (GPIO 3). Sniff the bus with an oscilloscope: without external pull-ups, the SCL clock edges will look like slow, rounded shark fins instead of crisp square waves.

3. I2C Address Clashes

The Symptom: Two identical sensors (e.g., two INA219 current monitors) are wired to the bus, but i2cdetect only shows one address.
The Cause: Both chips share the same default I2C address (e.g., 0x40).
The Fix: Consult the datasheet. Most sensors have an address-select pin (often labeled A0 or ADDR). Tying this pin to GND yields one address; tying it to VCC shifts the address. Use a multimeter to verify the voltage on the select pin before powering the bus.

Minimal Working Exchange: UART Bluetooth to Pi

Below is a complete, copy-pasteable Python script using the pyserial library to read MAC addresses from an HM-10 BLE module acting as a central scanner. This assumes you have physically wired the module through a logic level shifter and disabled the Linux serial console.

Pin Mapping Table:

import serial
import time
import sys

# Configure the mini-UART port. 
# Baud rate 9600 is standard for HM-10 AT command mode.
SERIAL_PORT = '/dev/ttyS0'
BAUD_RATE = 9600

def init_ble_scanner():
    try:
        ser = serial.Serial(SERIAL_PORT, BAUD_RATE, timeout=2)
    except serial.SerialException as e:
        print(f"Hardware fault or port locked: {e}")
        print("Ensure 'Serial Console' is disabled in raspi-config.")
        sys.exit(1)

    time.sleep(0.1)
    
    # Send AT command to verify communication
    ser.write(b'AT')
    response = ser.read(2)
    if response != b'OK':
        print(f"Unexpected response: {response}. Check TX/RX cross-wiring.")
        ser.close()
        sys.exit(1)
    
    # Set module to central (scanning) mode
    ser.write(b'AT+ROLE1')
    time.sleep(0.2)
    
    # Reset module to apply role change
    ser.write(b'AT+RESET')
    time.sleep(1.0) 
    
    print("Scanning for BLE peripherals... (Ctrl+C to stop)")
    return ser

def read_discoveries(ser):
    try:
        while True:
            # HM-10 outputs discovered MAC/RSSI strings directly to UART
            line = ser.readline()
            if line:
                # Decode and strip trailing carriage returns
                decoded = line.decode('utf-8', errors='ignore').strip()
                if decoded.startswith("OK+DISC"):
                    print(f"Found Device: {decoded}")
    except KeyboardInterrupt:
        print("\nStopping scan.")
    finally:
        ser.close()

if __name__ == "__main__":
    serial_conn = init_ble_scanner()
    read_discoveries(serial_conn)

By understanding that the Pi's onboard Bluetooth is essentially a hardwired UART peripheral, and by respecting the 3.3V logic and pull-up requirements of the exposed GPIO buses, you can reliably integrate both internal and external wireless protocols into your embedded designs without risking the hardware.