Concept renderBluetooth Low Energy (BLE) is the low-power side of Bluetooth. It uses 40 channels in the 2.4 GHz band and sends short bursts of data between long sleeps. A device announces itself by advertising, then exchanges data through GATT services and characteristics. It suits wearables and sensors that sync small amounts of data with a phone.
Many wearables, health bands and short-range tags talk to a phone over Bluetooth Low Energy. Picking the radio is the easy part. What the device advertises, how its data is laid out and how often it wakes decide battery life, discovery time and background behavior. This guide covers each one for a product team.
This summarizes vendor and Bluetooth SIG pages read in November 2026. We did not read the Bluetooth Core Specification, so confirm values against it and your chip vendor's documents.
What is Bluetooth Low Energy, and how does it work?
The Bluetooth SIG describes the LE radio as designed for very low power operation. It transmits over 40 channels in the 2.4 GHz ISM band and supports point-to-point, broadcast and mesh topologies (Bluetooth SIG technology overview, as of November 2026). In smart home devices built on the Matter protocol, BLE handles setup and the device then runs over Wi-Fi or Thread. For the low-power mesh radios in that space, see Zigbee vs Thread vs Matter.
The low power comes from the duty cycle. A BLE device sleeps most of the time and wakes for short radio events. It moves data by advertising, which any nearby scanner can read, or over a connection, where two devices exchange data on an agreed schedule.
TI's stack guide lists four roles: a broadcaster only advertises, an observer only scans, a peripheral advertises and accepts a connection, and a central scans and starts connections (TI BLE5-Stack user guide, as of November 2026). In most consumer products the phone is the central and the wearable is the peripheral.
Bluetooth vs BLE: how is it different from Classic Bluetooth?
Classic Bluetooth (BR/EDR) and Bluetooth LE share a brand and a band. The Bluetooth SIG compares them like this.
| Attribute | Classic (BR/EDR) | Bluetooth LE |
|---|---|---|
| Channels in the 2.4 GHz ISM band | 79 channels, 1 MHz spacing | 40 channels, 2 MHz spacing (3 advertising, 37 data) |
| Data rates by PHY | BR 1 Mb/s, EDR 2 Mb/s and 3 Mb/s | LE 2M 2 Mb/s, LE 1M 1 Mb/s, LE Coded 500 kb/s (S=2) and 125 kb/s (S=8) |
| Topologies | Point-to-point, including piconet | Point-to-point, broadcast and mesh |
| What the SIG says about use | Mainly wireless audio streaming: speakers, headphones, in-car systems | Designed for very low power operation, and now also widely used for device positioning |
Source: Bluetooth SIG technology overview, as of November 2026. The SIG lists the same maximum transmit power for both, 100 mW (+20 dBm), and notes that devices must stay within the limits set by local regulators.
PHY rates are air rates. Your app sees less after overhead and phone limits, so measure throughput on real phones. Audio is where the choice gets harder. The SIG calls Classic the standard radio behind wireless speakers, headphones and in-car systems, and LE Audio is the newer option on the LE radio. For a voice or recording product, read LE Audio vs Classic Bluetooth for AI wearables.
Range comes from the whole design. The Bluetooth SIG says it depends on the PHY, receiver sensitivity, transmit power, antenna gain and path loss, and runs from more than a kilometer down to less than a meter (Bluetooth SIG range page, as of November 2026). In a small wearable, the antenna layout and the body next to it usually decide where you land. See PCB antenna design for small devices.
How does BLE advertising work?
An advertiser sends its packets on three primary channels, numbered 37, 38 and 39. A scanner can send a scan request, and the advertiser answers with a scan response. Legacy advertising carries up to 31 bytes of data. Extended advertising, added in Bluetooth 5, raises the limit for advertising and scan response data to 1650 bytes and sends the larger data on secondary advertising channels, which use the data channels (TI BLE5-Stack user guide, as of November 2026).
The advertising interval is the main lever. Silicon Labs says too short an interval means high power consumption, and too long means high latency (Silicon Labs low power guide, SDK v9.1.0, as of November 2026). A common pattern is to advertise fast for a short window after a button press, then slow down. Pick both rates from a current budget, and time discovery at the slow rate on each target phone.
What to put in the advertising packet
Treat the 31 legacy bytes as a public notice that anyone in range can read. A common choice is a service UUID so the app can filter scans, plus a short name or a status byte. Leave out anything that identifies the owner or what the person is doing. On Android, if the app declares that it never derives location from scans, Google notes that some BLE beacons are filtered from the results (Android Bluetooth permissions, as of November 2026). Beacon-style products should test with that flag set.
What are BLE GATT services and characteristics?
Once connected, data moves through the Generic Attribute Profile, or GATT. Android's documentation explains the pieces (Android BLE overview, as of November 2026):
- GATT is a general specification for sending and receiving short pieces of data called attributes. All current BLE application profiles are based on it.
- GATT runs on the Attribute Protocol (ATT). Each attribute is identified by a UUID in a standard 128-bit format.
- A characteristic holds a single value and zero or more descriptors, such as a unit or a valid range.
- A service is a collection of characteristics, such as a heart rate service that holds a heart rate measurement.
- The Bluetooth SIG defines profiles, and one device can implement several.
GATT roles are separate from central and peripheral. The client sends requests and the server answers. In Android's activity tracker example, the phone is the GATT client and the tracker is the GATT server.
GATT decisions that last
The GATT table is a contract between firmware and the app, and it outlives the first release. Use SIG-adopted services where they fit. Put product data in custom services with their own UUIDs. Add a characteristic that reports the protocol version, so a future app can talk to old devices.
Packet size matters for bulk data. Android says that starting with Android 14, its stack requests an ATT MTU of 517 bytes when the first GATT client asks for an MTU, and ignores later requests. It also says a write without response is truncated to the MTU size (Android BluetoothGatt reference, as of November 2026). Make sure a smaller MTU on older phones still works.
Android also warns that data exchanged with a device paired over BLE is accessible to all apps on that phone, and advises app-layer security for sensitive data (Android BLE overview, as of November 2026). For health or voice data, encrypt above the link.
How do BLE connection intervals set battery life and speed?
Three parameters shape a connection. TI's stack guide gives these ranges, and it defines the effective connection interval as the connection interval times (1 + peripheral latency) (TI BLE5-Stack user guide, as of November 2026).
| Parameter | What it is | Range in TI's guide | Tradeoff |
|---|---|---|---|
| Connection interval | Time between connection events, in 1.25 ms units | 7.5 ms to 4.0 s | Shorter means more throughput and more power for both devices. |
| Peripheral latency | Connection events the peripheral may skip | 0 to 499 | Higher saves peripheral power while it has nothing to send, and delays data sent from the central. |
| Supervision timeout | Longest time allowed between two successful connection events | 100 ms to 32.0 s, and longer than the effective interval | Too short drops links in noisy rooms. Too long hides a lost device. |
The ranges and the first two tradeoffs come from TI's guide for the SimpleLink CC13x2 and CC26x2 SDK. The supervision timeout tradeoff is engineering reasoning.
Silicon Labs advises a short interval with no peripheral latency for short exchanges, and for longer connections with idle periods a somewhat longer interval plus peripheral latency, because too many empty packets raise power use (Silicon Labs, as of November 2026).
The phone has a say too. Android lets an app ask for a high priority connection, and Google says to use it only to move large amounts of data quickly, then return to balanced parameters (Android BluetoothGatt reference, as of November 2026). Log the parameters you actually get on each phone. For radio and sleep currents of two common chips, see nRF52840 vs ESP32 for wearables.
Match the link to how the product is used:
| Usage pattern | Link approach | What to watch |
|---|---|---|
| Broadcast only, such as a beacon | No connection. The advertising interval and payload carry everything. | The interval sets battery drain and discovery time. Anyone in range can read the payload. |
| Occasional sync, such as a band uploading stored readings | Connect, transfer with a short interval and no peripheral latency, then disconnect. | Buffer data on the device until the phone shows up. |
| Always connected for alerts or a button | A longer interval plus peripheral latency. | The phone app must stay alive in the background. |
| Bulk transfer, such as recordings | Ask for a faster connection and a larger MTU, then return to balanced settings. | Throughput depends on the phone. Measure it on each one. |
| Live audio | Classic audio profiles or LE Audio. | Different tradeoffs, covered in the LE Audio comparison. |
What do iOS and Android let your app do in the background?
Android
Google's background guide says scanning works while the app is not visible, but the process must be alive. To wake a stopped app when a device appears, it suggests a scan with a PendingIntent and discourages scheduled periodic scans. Background connections close if the process is killed. To hold a link open, it points to a connectedDevice foreground service or the companion device APIs, with launch limits from Android 12 (Android BLE background guide, as of November 2026).
Apps that target Android 12 or higher declare BLUETOOTH_SCAN to look for devices, BLUETOOTH_ADVERTISE to make the phone discoverable and BLUETOOTH_CONNECT to talk to paired devices, as each is needed. These are runtime permissions, and requesting any of them shows a Nearby devices prompt. Apps that target Android 11 or lower need ACCESS_FINE_LOCATION, because a Bluetooth scan could reveal the user's location (Android Bluetooth permissions, as of November 2026).
iOS
Apple's Core Bluetooth programming guide sits in Apple's documentation archive and was last updated in 2013, so treat it as background and test on current iOS. It says an app is suspended soon after it enters the background unless it declares the bluetooth-central or bluetooth-peripheral background mode. Even then, when every scanning app is in the background the phone scans less often, so finding a device can take longer, and a woken app has around 10 seconds to finish its task (Apple Core Bluetooth guide, archived, as of November 2026).
So buffer data on the device, expect the app to show up late, and make each sync short and resumable.
Does a BLE product need Bluetooth SIG qualification?
Yes. The Bluetooth SIG says all Bluetooth products must be qualified, under your own company's membership account. A Product Qualification Fee, set by membership level, applies to the first submission that includes a specific design, and later products with the same design are not charged. The name and model number used in qualification must match your marketing, and qualification must be done on or before the day you start to sell or distribute the product (Bluetooth SIG qualification page, as of November 2026).
Put membership and qualification in the launch plan early. FCC equipment authorization is a separate process, and its path depends on whether you use a pre-certified module or put the chip on your own board. See FCC Part 15B vs 15C for a BLE wearable.
What should you ask your hardware team?
Bring these to the first firmware and app review.
- Is the chip LE-only, and do we need Classic Bluetooth for anything?
- What goes in the 31 bytes of legacy advertising data, and what can a stranger learn from it?
- Which advertising interval after a button press, which when idle, and what does each cost in current?
- Which GATT services are SIG-adopted, which are custom, and how does the app read the protocol version?
- Which connection parameters does the firmware request, and what do we actually get on each target phone?
- What happens when the phone app is suspended for a day, and how much data can the device buffer?
- Who holds the Bluetooth SIG membership, and do the qualified name and model match our marketing?
For the chips and radios we design with, see platforms we design with.
How far does Bluetooth Low Energy reach?
It depends on the PHY, transmit power, antenna and obstacles. The Bluetooth SIG gives a span from more than a kilometer down to less than a meter (Bluetooth SIG, as of November 2026). Test range on the finished device, worn.
Do we need our own Bluetooth SIG membership?
The Bluetooth SIG says you must complete qualification under your company's membership account (Bluetooth SIG, as of November 2026). A supplier cannot do it for you under its account.
How can Duobay help with a BLE product?
Duobay develops custom devices with a Shenzhen engineering team: electronics, firmware, enclosure and, as an option, the phone app, plus samples and small batches. The advertising plan, GATT table and connection timing are part of that work. Source files are assigned to you at every paid gate. We do not publish prices, and initial calls are free. Tell us about your device.
If you want an advertising plan, a GATT table and a power budget checked against the phones your users carry, tell us about your device.
Sources. All pages accessed November 6, 2026. Vendor documents and platform rules change, so confirm current versions before you decide.
- Bluetooth SIG, Bluetooth technology overview (link)
- Bluetooth SIG, Understanding Bluetooth range (link)
- Bluetooth SIG, Qualify your product (link)
- Texas Instruments, Generic Access Profile, SimpleLink CC13x2 / CC26x2 SDK BLE5-Stack User's Guide 2.01.03.00 (link)
- Silicon Labs, Bluetooth LE Use Case-Based Low Power Optimization, Use Case 5, v9.1.0 (link)
- Android Developers, Bluetooth Low Energy overview (link)
- Android Developers, Communicate in the background (BLE) (link)
- Android Developers, Bluetooth permissions (link)
- Android Developers, BluetoothGatt API reference (link)
- Apple, Core Bluetooth Programming Guide, Core Bluetooth Background Processing for iOS Apps (documentation archive, updated 2013-09-18) (link)
Planning a device like this? Tell us what it needs to do. A Duobay engineer replies within 1 business day. Send a project brief →