Nordic nRF Series Compared: nRF52 vs nRF53 vs nRF91

Nordic Semiconductor produces distinct product families for different wireless connectivity needs — they are not a sequential generational upgrade. Choosing the right series before committing to a schematic avoids a fundamental architectural mismatch later.

Series Overview

nRF52 Series — BLE and Thread Workhorse

The nRF52 series is Nordic's most widely deployed BLE platform. It uses a single Cortex-M4F core at up to 64 MHz, running either the BLE stack (SoftDevice or Zephyr BLE) and the application together, or running BLE stack firmware with the application layer on top.

Why choose nRF52:

• Proven, deepest community of any Nordic series — the most answers, examples, and third-party module options exist here
• Ultra-low power: as little as 2.4 µA during BLE advertising at a 1-second interval (device-dependent; verify against the specific variant's datasheet)
• The nRF52840 adds USB 2.0 and 802.15.4 for Thread/Zigbee (see the nRF52 variants comparison for full variant breakdown)
• Both the legacy nRF5 SDK (SoftDevice) and nRF Connect SDK (Zephyr) are fully supported
• The largest choice of pre-certified radio modules from multiple vendors

Limitations:

• Single core means the BLE stack and application share CPU time; complex applications must manage SoftDevice timing constraints
• No LE Audio (Bluetooth audio streaming) support
• Maximum 64 MHz limits compute-intensive applications

Key variants: nRF52840 (most capable, USB, 802.15.4), nRF52833 (802.15.4, no USB), nRF52832 (BLE only, most widely deployed).

nRF53 Series — Dual-Core BLE with LE Audio

The nRF53 series (currently the nRF5340 and nRF5340-DK in production) uses two Cortex-M33 cores: an application core at up to 128 MHz and a dedicated network core at 64 MHz. The network core runs the BLE or 802.15.4 stack; the application core runs the user application. The two cores communicate via IPC (inter-processor communication) mailboxes.

Why choose nRF53 (nRF5340):

• LE Audio — Bluetooth 5.2 isochronous channels (ISO) and LC3 codec for synchronised audio streaming (True Wireless Stereo, Auracast broadcast audio). LE Audio is not possible on the nRF52 series
• Stack isolation — the network core handles BLE timing and stack operations independently, freeing the application core for application logic without SoftDevice timing constraints
• Higher performance — 128 MHz Cortex-M33 application core with TrustZone, DSP instructions, and hardware FPU
• Better security — TrustZone on both cores enables secure boot, secure key storage, and isolated execution environments

Limitations:

• nRF Connect SDK is required — the legacy nRF5 SDK does not support nRF53
• Dual-core firmware model requires new architectural patterns vs nRF52; migration is a new design, not a chip swap
• Currently one primary production device (nRF5340); nRF52 has more package and memory options across its five variants
• Smaller community and fewer off-the-shelf module choices than nRF52 (though growing rapidly)

Key variant: nRF5340 — 1 MB application flash + 256 KB network flash, 512 KB + 64 KB RAM, BLE 5.4, 802.15.4, USB.

nRF91 Series — Cellular IoT with GNSS

The nRF91 series is a fundamentally different product from the nRF52 and nRF53 — it is a cellular IoT System-in-Package (SiP) containing a Cortex-M33 application processor and an integrated LTE-M/NB-IoT modem. It has no 2.4 GHz radio and cannot do BLE.

Why choose nRF91:

• Integrated cellular modem — LTE-M and NB-IoT in a single package, eliminating the need for a separate cellular module (Sierra Wireless, u-blox, Quectel). The modem firmware is provided by Nordic and handles AT commands, network registration, and power management internally
• GNSS — the nRF9160 with the SICA suffix includes a GNSS receiver alongside the cellular modem; location acquisition and cellular uplink in one device
• Low power cellular — LTE-M and NB-IoT are designed for IoT duty-cycle patterns (long sleep, periodic transmit); the nRF9160 supports PSM (Power Saving Mode) and eDRX for multi-year battery life on suitably small data payloads
• Modem sandbox — the application core and modem core are isolated; application firmware upgrades via FOTA (Firmware Over-The-Air) without touching the modem firmware

Limitations:

• No BLE radio — products needing cellular + BLE require a companion nRF52/53 SoC connected via UART or SPI
• Requires a SIM and active cellular contract — more operational complexity than BLE-only products
• Antenna design and cellular regulatory certification add product development complexity
• Smaller community than nRF52, but Nordic provides comprehensive application notes and the Thingy:91 reference design

Key variants: nRF9160 (LTE-M + NB-IoT + GNSS), nRF9161 (updated nRF9160 with improved performance and modem firmware features), nRF9151 (smaller package, 2 MB flash).

nRF54 Series — Next Generation (Evaluate for New Designs)

The nRF54 series was announced in 2024 as Nordic's next-generation BLE platform, intended to succeed the nRF52 and nRF53. The nRF54L15 (as of mid-2026, in sampling or early production — verify current availability) is a single Cortex-M33 at up to 128 MHz with BLE 5.4 and LE Audio support, 1.5 MB flash, and 256 KB RAM. It is designed to bring LE Audio capability to a single-core device without the dual-core complexity of the nRF5340.

The nRF54H20 is a multi-core variant targeting higher-performance applications. Both require nRF Connect SDK.

For designs with a long production horizon (2026 and beyond), evaluate the nRF54L15 — it may simplify LE Audio-capable designs compared to the nRF5340. For mature, lower-risk production today, the nRF52840 and nRF5340 have deeper production histories and module availability.

Choosing by Application Type

SDK and Toolchain

All current Nordic series are supported in nRF Connect SDK (NCS), which is based on Zephyr RTOS and the west meta-tool. NCS is the required development framework for nRF53; it is the recommended path for new nRF52 and nRF91 projects as well.

The legacy nRF5 SDK (SoftDevice-based) supports nRF52 only and receives maintenance updates but no new features. Existing nRF5 SDK projects on nRF52 are stable; new nRF52 projects should start with NCS.

For setting up an NCS project, see How Do You Set Up the nRF Connect SDK and Zephyr RTOS for nRF52 Development? — the toolchain setup steps apply equally to nRF52, nRF53, and nRF91 targets.

Common Mistakes

Choosing nRF53 as a "more powerful nRF52840" — The nRF5340 is not simply a faster nRF52840. The dual-core architecture requires a different firmware model, nRF Connect SDK is mandatory, and the community is smaller. Unless your application specifically needs LE Audio or the separate network core, the nRF52840 is the simpler and lower-risk choice.

Using nRF91 for a BLE application — The nRF9160 and nRF9161 have no 2.4 GHz radio. Engineers familiar with nRF52 sometimes assume all nRF devices do BLE. If BLE is required, use nRF52 or nRF53; if both cellular and BLE are required, use a dual-chip design.

Selecting nRF52832 when 802.15.4 is needed — The nRF52832 does not support Thread or Zigbee; it is BLE-only. The nRF52840 or nRF52833 are the correct choices when 802.15.4 is a requirement. See nRF52 variants compared for the full peripheral-by-variant breakdown.

Not validating module availability for your region — nRF52-based certified modules are widely available from many vendors (u-blox, Raytac, Fanstel, and others); nRF5340 modules are fewer. For an Australian product requiring RCM certification, identify which modules carry ACMA/RCM certification before committing to a SoC variant.

If you're building a commercial product on the Nordic platform, Zeus Design develops nRF BLE and IoT firmware from bring-up through to production.