Choosing the BLE host for a battery device comes down to sleep current and stack footprint, settled well before any line on the BLE 5 feature list matters. Two parts that advertise the same radio version can differ by an order of magnitude in what they draw between connection events, and that gap is what decides the battery.

The host is the single chip that runs both the radio and the application, so picking it pulls in the protocol stack it has to hold in flash, the RAM it keeps alive through sleep, and the certification path its vendor offers. A coin cell sensor and a rechargeable wearable start from opposite ends of that list, and the part that fits one rarely suits the other. The update needs and the unit cost pull the choice as hard as any radio number does.

When BLE is the radio to reach for

BLE is the default for a battery device that sends short, infrequent data to a phone or a nearby gateway, and the case for it rests on the connection model more than on raw range or speed. The radio sleeps between brief connection events, wakes on a schedule the central side helps set, and spends almost nothing when there is nothing to say. Where a design instead has to move a firmware image in minutes, or reach across a building without hops, the question of whether BLE is the right radio at all deserves an honest answer before any SoC shortlist forms. For the wide class of sensors and tags that wake briefly to pass a little state and then sleep, it wins on the energy spent per delivered byte, and that is the number a battery product ends up paying.

What separates one BLE SoC from another

Strip away the feature checklist and a short set of numbers decides a BLE SoC for a battery design. They live in the datasheet rather than the brochure, and reading them in the right order saves a redesign that a late current measurement would otherwise force.

The first number is the sleep current with RAM retained and a timer running, because that current flows for nearly the whole life of a device that wakes a few milliseconds at a time. Parts in this class sit anywhere from a few hundred nanoamps to several microamps in that state, and the spread traces to how much RAM stays powered and how the low frequency clock is sourced. The second is the memory the protocol stack consumes: a BLE stack and its host take tens of kilobytes of flash and a block of RAM that has to stay alive, so a part with 256 kB of flash and a peripheral-heavy application can run short in a way the radio spec never hints at. The third is the radio current during transmit and receive, which sets the energy of each connection event, and a part that idles beautifully yet draws fifteen milliamps on receive can lose to one that idles a little higher and receives at half of that. The arithmetic that ties these together is short: at a one second connection interval the radio wakes about once a second, each wake spends a fixed charge measured in microamp-hours, and the average current is the sleep figure plus that charge multiplied by the wake rate. Stretch the interval and the event term shrinks while the sleep term stays where it is, which is why a slower update is usually the cheapest power saving a BLE design has, and why the sleep number sets a floor that no connection setting gets under. A mainstream design that wants a proven stack and a deep pile of examples often starts with a mid-range host like the nRF52832, while a design chasing the longest coin cell life looks at the newer low power parts such as an EFR32BG22 built around battery life. The clock counts for more than it looks, since a part that runs its sleep timer from a cheap 32 kHz crystal, or from an internal RC trimmed against the main clock, saves both the current and the board space of a precision part, at some cost in timing accuracy that shows up as a wider receive window.

Two more numbers ride alongside the power figures. Receive sensitivity and output power set the link budget, and a few dB of sensitivity buys back range that a design would otherwise pay for in transmit current or a larger antenna, so the gap between a part rated near minus 96 and one near minus 103 dBm can decide whether a link holds across an open flat or drops at the far room. The firmware update path costs memory that is easy to forget, since a device taking an over the air update usually needs room for a second image bank or an external flash chip, and that requirement can push the flash a design needs past what the cheapest part in a family offers.

One question reshapes the shortlist before any parts get compared, which is whether the radio has to speak anything besides BLE. A device that must also join a Thread or Matter mesh needs a multiprotocol part, and that requirement alone clears the single-mode bargains off the table. A part that has to run BLE for commissioning and Thread for the working traffic also has to time-slice one radio between them, so the stack and the silicon both need to support that handover cleanly rather than bolt it on later. Where BLE is the only radio the product will ever run, the cheaper single-mode parts come back into play.

Where the families land

Nordic's nRF52 line is where a lot of BLE designs start, helped by a stack and toolchain that many engineers already carry from a previous product. At the top of it sits the nRF52840 with its multiprotocol radio, native USB, and the larger flash that an OTA-capable or Thread-joined product tends to need. It carries a Cortex-M4F with a megabyte of flash and a quarter megabyte of RAM, which is the room those features ask for, and it backs them with hardware crypto that a secure boot or an encrypted link leans on. The part costs more than the mainstream member of the family and draws a little more in active modes, so it earns its slot when the extra memory or the second protocol is a real requirement and not a maybe.

When security and a clean update story carry weight, the nRF5340 splits the application and the network onto separate cores, which keeps the radio stack running isolated from application code and makes a compromised app harder to turn into a compromised radio. The application core can clock up when it has work and idle low when it does not, while the network core holds the radio timing on its own, so the two jobs stop fighting over one budget. The split adds build and debug complexity that a simple beacon never needs, so it pays off on the products where the firmware is going to grow over years and sit on a network that someone will probe.

At the other end of the line, cost sets the terms. The DA14531 strips a BLE node down to a few cents of silicon in a package small enough to tuck under a button, with a modest slab of memory that holds a connection and little more, which is the point for a disposable tag or a single-function remote counted to the cent. The TLSR8258 holds onto low cost while keeping a multiprotocol radio, a pairing that turns up across lighting and other high volume connected goods where a few cents repeated a million times is the whole margin, and where the same part has to speak BLE to a phone and a mesh protocol to its neighbors. Neither part leaves much headroom, so the application has to stay lean, and a developer used to the room on a mainstream host learns to watch the linker map from the first build. The point of these parts is the price, and they reach it by giving up flash and the comfortable margin that a roomier host would carry.

Texas Instruments answers the same battery question with the CC2640R2F and its low power BLE connectivity, pairing a Cortex-M3 with a separate sensor controller that can sample and watch inputs while the main core stays asleep. That second core lets a sensor node collect readings on a schedule and only wake the application when something crosses a threshold, which trims the average current on the kind of workload that would otherwise keep a full core awake to do almost nothing. It tends to land in designs already built around the TI ecosystem, where the toolchain and the rest of the parts list pull the same way.

Lined up together, these parts sort less by their radio than by the memory and the protocol mix around it.

Module or bare SoC

A bare SoC gives the lowest unit cost and the tightest control over the board, at the price of designing the RF section and carrying the radio through regulatory testing. A module hands both of those jobs to its vendor for a higher per-piece cost, and choosing between them turns on volume and on how much radio experience the team can call on. A team that has shipped a few antennas can take the saving; one that has not can spend its first tuning attempt learning why the range came in low.

For a small run or a first product, a precertified module like the BGM220P takes the antenna design and the bulk of the certification work off the team, because the module ships with its radio approvals already granted. The approvals are more than one stamp: a finished radio has to clear regional regulatory limits, the FCC kind in one market and CE in another, and a Bluetooth product also needs a qualification on the Bluetooth SIG side before it can carry the logo and ship. A precertified module arrives with the modular regulatory grant and a qualified design already on file, so what remains is mostly paperwork that inherits those approvals rather than a fresh test campaign that can run into weeks.

As volume climbs, the per-piece premium of a module starts to outweigh the engineering it once saved, and a product that launched on a module often moves to a bare SoC for its second generation. The same logic runs the other way for a niche product that will never reach those volumes, where a module stays the cheaper answer for the life of the design because the engineering to replace it never pays back. The host choice is rarely permanent, and it tracks where a product sits in its life about as closely as it tracks what the radio can do.