RF Wireless World

Browse articles, tutorials, tools, and vendors.

Bluetooth Bit Stream Processing: HEC, CRC, FEC & More

By RF Wireless Expert Team

If you want to send a delicate package through a chaotic postal system, you don’t just hand the postman the fragile item as is. You put it in a box, add packing peanuts, seal it with tamper evident tape and stick a highly visible shipping label on it.

Bluetooth does the exact same thing with digital data. You cannot simply blast raw 1’s and 0’s into the noisy 2.4 GHz wireless spectrum and expect them to survive. Before a packet reaches the physical radio antenna, the Bluetooth Baseband passes the data through a strict assembly line called Bit Stream Processing.

This pipeline applies checksums, encryption, scrambling and error correction mechanism. Let’s explore how this pipeline works, examining the specific stages viz. CRC, HEC, Encryption, Whitening and FEC.

The 5 Stages of Bit Stream Processing

The processing pipeline is divided into two separate tracks: one for the Packet Header (the routing label) and one for the Payload (the actual user data).

1. The Checksums: HEC and CRC

Before the data leaves, Bluetooth attaches mathematical seals to ensure it isn’t corrupted in transit.

  • For the Header (HEC): The Baseband calculates an 8-bit Header Error Check (HEC). To ensure a device only accepts packets from its own network, the HEC generator is mathematically “seeded” (initialized) using the unique Upper Address Part (UAP) of the Central device’s Bluetooth MAC address.

  • For the Payload (CRC): A 16-bit Cyclic Redundancy Check (CRC) is calculated and appended to the end of the payload.

  • Note: Only certain packet types get a CRC. Real-time audio SCO packets skip this to save time.

2. Security: Encryption

Next, if the connection is secure, the payload is locked. Bluetooth uses algorithms like AES-CCM (or legacy E0) to generate a cryptographic key stream. The payload data and its attached CRC are bitwise XORed with this key stream, turning the data into ciphertext.

  • Note: Only the payload is encrypted. The Packet Header is always sent in plain text so the receiving hardware knows how to route the packet before decrypting it.

3. Scrambling: Data Whitening

Radio receivers hate long strings of identical bits such as 00000000 or 11111111. Long stretches of zeroes or ones cause a “DC bias” in the circuitry, making it hard for the receiver to maintain timing synchronization.

To fix this, Bluetooth applies Data Whitening. It uses a Linear Feedback Shift Register (LFSR) seeded by the Central’s clock to generate a pseudo random sequence of noise. Both the Header and the Payload are XORed against this noise. This “scrambles” the bits, ensuring an even mix of 1s and 0s over the air.

4. FEC (Forward Error Correction)

Finally, Bluetooth adds redundancy so the receiver can correct minor bit errors without asking for a retransmission.

  • Rate 1/3 FEC: Used for the vital Packet Header. It simply repeats every bit three times. A 1 becomes 111, and a 0 becomes 000. If the receiver sees 101, it mathematically guesses that the sender meant 111 (a 1).
  • Rate 2/3 FEC: Used for certain data payloads such as DM1 packets. It uses a shortened Hamming code that adds 5 parity bits for every 10 data bits. It is less bulky than 1/3 FEC but can still automatically fix single bit errors in a block.

Stepwise Guide to Bluetooth Bit Processing with example

Let’s walk through a real world scenario. Imagine a smartwatch (Peripheral) is sending a tiny piece of health data (like heart rate = 75 BPM) to a smartphone (acting as Central). The data will be sent in a DM1 packet (which includes payload FEC).

Step 1: INPUT (i.e. Raw Materials)

  • Header Data: LT_ADDR = 1, TYPE = DM1, SEQN = 1, ARQN = 1. (10 bits total).
  • Payload Data: “75” (User data).

Step 2: Attaching Checksums

  • Header: The system takes the 10 header bits, factors in the Smartphone’s UAP, and generates an 8-bit HEC. The header is now 18 bits long.
  • Payload: The system takes the heart rate data, calculates a 16-bit CRC, and attaches it to the end of the payload.

Step 3: Encryption

  • The smartwatch generates the AES-CCM encryption stream.
  • The Payload + CRC are XORed against this stream. The heart rate data is now unreadable ciphertext. (The 18-bit Header remains untouched).

Step 4: Data Whitening

  • The smartwatch looks at the smartphone’s internal clock and seeds the Whitening generator.
  • It generates a stream of pseudo-random static.
  • The 18-bit Header and the Encrypted Payload are XORed with this static to balance the 1s and 0s.

Step 5: Applying FEC Mechanism

  • The whitened Header gets Rate 1/3 FEC. Every bit is tripled.
  • The whitened, encrypted Payload gets Rate 2/3 FEC. Parity bits are woven into the data blocks to provide error correcting capabilities.

Step 6: Transmission

Finally, the Baseband takes the smartphone’s Access Code, attaches the 54-bit Header, attaches the heavily armored Payload, and hands it to the physical radio antenna to be blasted over the 2.4 GHz frequency channel.

The Receiving End

When the smartphone receives this packet, it runs the exact same pipeline in reverse:

  1. It strips the 1/3 FEC from the header, fixing any minor errors.
  2. It de-whitens the header and payload using its own clock.
  3. It checks the HEC. If the HEC passes, it accepts the packet.
  4. It strips the 2/3 FEC from the payload.
  5. It decrypts the payload.
  6. It calculates the CRC. If the CRC matches, the smartphone knows the heart rate data (“75”) arrived flawlessly, and it will send an ACK in its next transmission!

References & Further Reading

  1. Bluetooth SIG : Bluetooth Core Specification Version 6.3, May 5, 2026.
  2. Bluetooth SIG : Bluetooth Core Specification change history
  3. Bluetooth SIG : Bluetooth Technology Overview

Continue Learning Bluetooth Basic Concepts

Continue Learning Bluetooth Technology

Compare Bluetooth With Other Technologies

Explore Deep Insight Bluetooth Technology

Keep Reading

Related Posts