Selecting the Right Nordic nRF52 for BLE

The nRF52 is a family of Bluetooth Low Energy systems-on-chip, spread across seven members. The lineup runs from a two-by-two-millimeter die for an earbud up to a part with a megabyte of flash, a USB port, and four wireless protocols. A BLE design picks one member by three things: the memory its software stack needs, the radio protocols the product has to speak, and the power its battery can give. A wrong pick shows up late, as a stack that overflows the flash or a part that cannot reach a second protocol the roadmap added. Reading the family by those three axes puts the right nRF52 on the board the first time.

The nRF52 family, member by member

The nRF52 line runs from a small, single-protocol part up to a full multiprotocol flagship. Every member shares the same Arm Cortex-M4 core, the same 2.4 GHz radio architecture, and the same Nordic toolchain. Moving across the family takes one set of skills. The member changes the memory, the protocols, and the peripherals around that shared core. The 64 MHz Cortex-M4 gives every part enough compute for a sensor, a wearable, or a smart-home node, with cycles to spare for the application on top of the radio work. The radio runs the 2.4 GHz band at 1 and 2 megabit Bluetooth rates, plus the long-range coded modes that trade speed for reach. A team that knows one nRF52 reads the next one’s datasheet in an afternoon. Packages run from a tiny wafer-level chip-scale ball grid for the smallest parts to a leaded QFN for an easy hand-layout. The package decides the board area and the routing as much as the silicon inside it. Pin count tracks the package, so the larger members expose more GPIO, more analog inputs, and more serial ports for a richer product. The shared peripheral set covers the usual SPI, I2C, UART, ADC, PWM, and timers across the family. The large members carry more of each block than the small ones. The PPI feature on the family lets peripherals trigger each other in hardware. The core stays asleep through it, the same trick that stretches a sensor’s battery. One peripheral reads a sensor on a timer, hands the result to memory, and wakes the core only on a threshold. Reading the peripheral count and the channel count on the datasheet, against the product’s sensor list, confirms the chosen part has the pins and the blocks the design needs.

The small parts hold the entry of the line. The nRF52805 packs a Bluetooth radio into the smallest Nordic footprint, the size an earbud or a tag needs. The nRF52810 is the cost part for a plain Bluetooth sensor. The nRF52811 adds the 802.15.4 radio at that same low cost, the entry point to Thread and Zigbee. These three run a Cortex-M4 without the floating-point unit, with flash near 192 KB and RAM near 24 KB. A simple beacon, a switch, or a single-sensor tag fits inside that envelope. The nRF52811 stands out among the three, since it carries the 802.15.4 radio at the entry price, the cheapest path onto a Thread or a Zigbee mesh. A design that wants mesh on a budget starts there. The nRF52805 trims the pin count and the package to the bone for the tightest products. The nRF52810 holds the plain Bluetooth role at the lowest cost of the line. The three small parts share the memory ceiling, so a stack that outgrows the 192 KB moves the design up to the mainstream tier regardless of which small part it began on. Long-range coded Bluetooth is the other reason to reach for the 52811, since its radio reaches the kilometer-class link the coded modes allow. An asset tracker or an agricultural sensor uses that reach. The small parts share one profile: little memory and one or two protocols. They hold the lowest price in the line. The selection inside this tier comes down to the radio: plain Bluetooth on the nRF52805 and nRF52810, the added 802.15.4 on the nRF52811. The memory and the core stay constant across the three, so the radio need points straight at the part.

The mainstream sits in the middle. The nRF52832 is the part a great many Bluetooth products ship on, a Cortex-M4 with the floating-point unit, flash up to about 512 KB, and an NFC tag for pairing. The nRF52833 lifts the memory near 128 KB of RAM, adds a USB port and the 802.15.4 radio, and holds its rating to a wide temperature range for an industrial product. The 52833 also carries the radio direction-finding features that locate a tag in a room, the angle-of-arrival and angle-of-departure modes a real-time location system uses. Indoor asset tracking finds those features on the 52833. The nRF52820 sits below it, a smaller multiprotocol part that adds USB to the entry tier. The mainstream tier is where a design lands when the small parts run short on memory. The Cortex-M4F core on these parts runs the floating-point math a richer application leans on, the audio filter or the sensor-fusion step a wearable adds. The step up from the entry tier buys that compute along with the memory.

The nRF52840 is the flagship. Nordic gives it a megabyte of flash, 256 KB of RAM, USB, a hardware security block, and the highest output power in the family. It runs Bluetooth, 802.15.4, Thread, and Zigbee on one die. The security block is an Arm CryptoCell unit that holds keys and runs encryption apart from the application, the foundation a connected product needs for secure boot and a protected identity. The QSPI interface lets the part run code or data from an external flash chip. The on-board megabyte stops being the ceiling. A design that wants room for a large stack, several protocols, and a security story reaches for the 52840.

Memory sets the floor

The Bluetooth stack lives in the flash next to the application. Nordic ships that stack as a precompiled binary, the SoftDevice, with its own flash and RAM claim. A bare peripheral on the nRF52810 fits the 192 KB part with room for a small application. Nordic ships the stack in graded versions, the S112 for a peripheral, the S132 for a central, the S140 for the multiprotocol parts, each with a different memory claim. The headroom of the 52832 or the 52840 covers a central device that holds many connections, or a product that runs a full operating system over the stack. A firmware-update scheme adds its own demand, since a safe over-the-air update keeps two images in flash at once, which doubles the room the application takes.

RAM is the tighter constraint on the small parts. The SoftDevice reserves a block of RAM for the link layer. Several connections or large buffers run a design out of the 24 KB on an entry part. Reading the SoftDevice memory claim against the part’s flash and RAM, early in the design, settles whether the small part holds the whole job. The memory floor rules out a part before its price or its package matters. A design that picks on price alone, then finds the stack and the update images overflow the flash, pays for the mistake with a board respin. The honest count happens first: the SoftDevice, the application, the buffers, and the second update image, all summed against the part’s flash and RAM. A master boot record and a bootloader take their own slice of flash at the bottom of the map, below the SoftDevice. Nordic’s memory layout documents spell out where each piece sits. Sketching that map on the chosen part, before the schematic, is the cheapest insurance against a flash overflow late in the build. RAM tells the same story from the other side. The link layer holds a buffer for every connection, so a hub talking to a dozen sensors claims far more RAM than a single-link tag. Counting the live connections at peak, times the per-link buffer, gives the RAM number the part has to clear. The small parts run out of RAM long before they run out of flash on a multi-connection design.

Match the radio to the job

The radio protocols split the family into two camps. One camp speaks Bluetooth alone, for a product whose wireless need is a phone or a Bluetooth gateway. The other adds the 802.15.4 radio, the physical layer under Thread and Zigbee. The design names the protocols its product has to speak today and the ones the roadmap will add, then reads the family by that list. The cost of guessing low here is a second board. Build on a Bluetooth-only part, then get asked to join a Thread network a year later, and the product needs a new chip and a new layout. Naming the future protocols at the start picks a part that already carries the radio for them.

Thread and Zigbee open the smart-home mesh. A product that joins a Matter network over Thread needs the 802.15.4 radio, so the choice lands on the nRF52811 at the low end or the nRF52833 and nRF52840 higher up. Nordic documents the nRF52840 as fully multiprotocol with full protocol concurrency, which lets one chip hold a Bluetooth link for setup and a Thread mesh for the network at the same time. A product that commissions over Bluetooth and then runs on Thread reads that concurrency as the deciding feature. Matter has pulled many smart-home designs onto this path, since the standard pairs a Bluetooth setup flow with a Thread transport. A light, a lock, or a sensor on the Matter standard lands on a part that carries both radios. The nRF52840 covers that whole requirement on one chip. Zigbee covers the older smart-home and lighting installs, on the same 802.15.4 radio. A product that has to join an existing Zigbee network reads the same multiprotocol parts as a Thread one. The radio hardware serves both standards, so the choice of mesh stack stays a software decision on a part that carries the 802.15.4 PHY. Nordic supplies the Zigbee stack and the Thread stack for the multiprotocol parts, certified against the standards bodies. The certification travels with the silicon, so a product inherits it. Picking a part with the radio is the hardware half of the decision; the stack and the certification are the software half Nordic already holds.

USB is the next axis. Talking to a host over a cable, or updating firmware over USB, needs a part with the controller built in. USB lives on the nRF52820, the nRF52833, and the nRF52840. A design that needs the cable picks from those three. USB also opens a clean firmware-update path, since a dongle or a wired product loads new code over the same cable a host already uses. A Nordic USB dongle built on the nRF52840 ships as a common sniffer and gateway for exactly that reason. Development itself leans on USB on the parts that have it, since a dongle programs and debugs over the one cable. Bluetooth itself can also carry a firmware update, through Nordic’s device-firmware-update service, on any part in the family. The update path is part of the selection, since a product in the field has to take new code somehow.

Concurrency separates the high parts from the entry ones. An entry multiprotocol part runs one protocol at a time and switches between them. The nRF52840 runs several at once, with the radio shared across them on a schedule. A product that stays reachable on Bluetooth during its mesh traffic depends on that concurrent operation. The radio is a single resource, so the SoftDevice time-slices it between the protocols, fitting each one into the gaps the others leave. Any design that leans hard on concurrency reads the timing of its links against that schedule, to confirm both fit.

The protocol list points to a small set of parts every time. A plain Bluetooth sensor lands on the nRF52810 or the nRF52832. The low-cost Thread or Zigbee node lands on the nRF52811. The USB-connected multiprotocol product lands on the nRF52833. The flagship that runs everything at once lands on the nRF52840. The job names the part long before the datasheet comparison begins. This is the heart of selecting an nRF52: the protocol list does the heavy lifting, narrowing a family of seven down to two or three candidates in a sentence. The memory floor and the power budget then settle which of those two or three goes on the board. Cost ranks the survivors at the end. Parts inside one tier price close together, so a few cents rarely decides. The price climb between tiers reflects the memory and the protocols. The discipline is to pick the smallest part that clears the memory floor and the protocol list.

The SoftDevice and the SDK

The software side stays the same across the family. Nordic ships the SoftDevice protocol stack and the nRF5 SDK, along with the newer nRF Connect SDK built on the Zephyr operating system. A team learns one flow and carries it from the nRF52810 to the nRF52840. The radio, the stack, and the certification come from Nordic together, so a product reaches a working, qualified Bluetooth link in days. The newer nRF Connect SDK marks the direction Nordic points new designs, on the Zephyr operating system the wider industry has adopted. A fresh project starts there. An existing nRF5-SDK product keeps running on the older flow, supported across the same parts. The Bluetooth qualification and the radio certifications travel with the part, so a product inherits them in its own filing. Nordic’s online power profiler and the development kits let a team measure the real current of a design before the board exists. The battery estimate becomes a measured number. That early measurement feeds straight back into the part choice, since a current figure higher than the budget sends the design to a lower-power setting or a different member.

Power, range, and the antenna

Battery life is the reason a product reaches for the nRF52 at all. The family holds deep sleep currents in the low microamps, with the radio waking only for an advertising or a connection event. A coin-cell sensor that talks for a few milliseconds every second runs for years on that budget. The application code and the wake schedule set the real battery life, on top of the part’s own sleep current. The transmit burst draws a few milliamps for a few milliseconds. The deep sleep between bursts drops to a couple of microamps. The real-time clock and the RAM stay alive through it. The average over a day comes from how often the radio wakes, so a sensor that reports once a minute outlasts one that streams every second.

Output power sets the range. Most of the family transmits up to about +4 dBm. The nRF52840 and the nRF52833 reach +8 dBm, the highest in the line, for a link that has to cross a house or a factory floor. The extra range comes from one of those parts or from an external power amplifier. The higher output draws more current on transmit, so the power budget gets read against the range target. An on-chip DC-to-DC regulator cuts the current the part draws from the battery, a setting a coin-cell product turns on for the saving. The choice of advertising interval, connection interval, and transmit power together set how long the cell lasts. Tuning those three to a battery target takes the same care as picking the part.

The antenna decides the last few decibels. A chip antenna, a printed trace, or an external whip each carries its own size and its own gain. The match between the radio and the antenna costs real range when it drifts. A team that lacks RF experience reaches for a Nordic module, which carries the radio, the crystal, and a tuned antenna on a shielded board with a regulatory certification already in hand. The matching network is a few small parts between the chip and the antenna, tuned to put as much energy as it can into the air at 2.4 GHz. A reference layout from Nordic gets that match right, so a design that copies the reference keeps its range. The decibels lost to a drifting layout are decibels the link can ill afford.

From the family to the part

The module decision rides alongside the part decision. A bare nRF52 die costs the least and gives the smallest board, for a team that can lay out and certify its own RF. A pre-certified module carries the radio section and the regulatory paperwork, for a team that wants to skip the antenna tuning and the test lab. The module’s higher unit price buys a faster path to a certified product. A first product or a small run leans on the module for that ready certification. Supply enters the choice as well. The popular parts and modules stock widely across distributors. A qualified second source is easier to hold on the mainstream nRF52832 and nRF52840 than on a niche member. A design names a backup part early, so a shortage on one member moves to another inside the same family with a recompile. The shared core and the shared SDK make that move cheap, since the application layer carries across with the peripheral count checked. The whole point of reading the family by memory, protocols, and power is that it leaves a clear runner-up, the next part up that also clears the three axes. That runner-up is the second source a robust design qualifies before it ships. The whole method takes an afternoon, far less than the cost of a respin. Listing the protocols, summing the memory, setting the power budget, then reading the seven members against those three lines, lands on the right part with a named backup beside it. The nRF52 family rewards that order of work, since its members sort cleanly along exactly those axes.

The pick comes down to the three axes, read in order. The memory floor rules out the parts too small for the stack. The protocol list narrows the field to the parts that speak what the product needs. The power and the range settle the last choice among what remains. The family runs from a small part like the nRF52810 for a plain coin-cell sensor up to the nRF52840 for a multiprotocol smart-home product that runs Bluetooth and Thread at once. The family is wide enough that one of its members fits almost any Bluetooth design, once the design reads its own needs honestly.