The Nordic nRF9151 Just Merged Cellular and Satellite IoT — What Firmware Engineers Building NTN Devices Need to Know

Building firmware for the nRF9151 modem that switches between cellular and satellite IoT

You’d think putting cellular and satellite on one modem would make the firmware simpler. It doesn’t. The nRF9151 collapses LTE-M, NB-IoT, and NB-NTN into a single chip, but the chip won’t decide for you which network to camp on. That decision, when to try terrestrial, when to fall back to satellite, when to give up and retry, lives entirely in your code. And that’s the part Nordic’s docs and the 3GPP specs leave you to figure out.

If you’re already shipping NB-IoT or LTE-M and you’ve got a mandate to add satellite coverage, this is the guide for the gap. No cellular 101. Just the dual-mode selection logic, the timing assumptions that break, and one lighter architecture worth ruling out before you commit sprint time.

What the nRF9151 Actually Merges

One modem, three access modes: LTE-M, NB-IoT, and NB-NTN (3GPP Release 17 narrowband IoT over non-terrestrial networks). The NTN part is new. If you’ve built on the nRF9160, most of your muscle memory transfers.

Same AT command interface, same modem library, same general SDK shape under the nRF Connect SDK. The nRF9151 is smaller and pin-count-different, so it’s not a footprint drop-in, but your application layer mostly ports. What’s genuinely new is the NTN stack and everything that hangs off it: GNSS-gated attach, Doppler compensation, and much longer acquisition windows.

Be clear about what NB-NTN is not. It’s not direct-to-satellite phone service, no voice, no browsing. It’s narrowband IoT packets over GEO or LEO NTN carriers, brokered by a carrier like Skylo. Think a few hundred bytes when terrestrial coverage isn’t there, not a data pipe.

| Mode    | Use case               | Latency | Power  | Data cost |
|---------|------------------------|---------|--------|-----------|
| LTE-M   | Terrestrial, higher BW | Low     | Medium | Low       |
| NB-IoT  | Terrestrial, low BW    | Low     | Low    | Low       |
| NB-NTN  | Satellite fallback     | Seconds | High   | High      |

Sony’s ALT1250 covers similar Rel-17 ground, so the nRF9151 isn’t alone in dual-mode NTN. But if your stack already lives in the Nordic ecosystem, the 9151’s toolchain continuity is the main reason to stay.

The Hard Part: Dual-Mode Network Selection Logic

The modem won’t intelligently prefer cellular and fall back to satellite on its own. You write the policy that fits your power and cost budget.

The inputs your selection logic has to weigh:

  • Terrestrial signal availability (is there an LTE-M or NB-IoT cell in range?)
  • GNSS fix status: NTN attach needs a valid position and timing before it’ll work
  • PLMN priority and which operators you’re allowed to camp on
  • Cost tier: NTN bytes are far more expensive than terrestrial
  • Power budget: GNSS plus a long NTN acquisition drains real energy

The GNSS gating is the sequencing trap people miss. NTN attach depends on the modem knowing where it is and precise timing, so you have to get a GNSS fix before attempting NTN. On the nRF9151 the modem and GNSS share the RF front end, so you can’t run both flat out at once. Get your fix, then hand the radio to NTN. If your firmware tries to attach NTN cold without position, it’ll just burn time and battery failing.

On the AT layer you’ll be driving system mode and access technology with %XSYSTEMMODE, controlling attach with +CFUN, and reading network state with +CEREG. GNSS comes up through the modem’s GNSS interface rather than a single AT verb. Verify every one of these against your exact nRF Connect SDK version. The NTN-related commands and their parameters have moved between releases, and conceptual-only knowledge won’t save you here. Pin the SDK version, read its release notes, and test the actual responses.

There’s another quiet spot here: switching triggers and hysteresis. If you flip to NTN the instant cellular drops and back the instant it returns, you’ll ping-pong at coverage edges and waste power on repeated attaches. Add a dwell timer on each mode and a hysteresis margin so a brief signal blip doesn’t trigger a full satellite acquisition.

        +-------------------+
        |   BOOT / IDLE     |
        +---------+---------+
                  |
                  v
        +-------------------+
        | Scan Terrestrial  |<-----------------+
        | (LTE-M / NB-IoT)  |                  |
        +----+---------+----+                  |
             |         |                        |
     found   |         | no coverage            | cellular
             v         v                        | restored
     +-------------+  +------------------+       |
     | CELLULAR    |  | Get GNSS fix     |       |
     | ATTACHED    |  | (required for NTN)|      |
     +-------------+  +---------+--------+       |
                                |                |
                                v                |
                      +-------------------+      |
                      | NTN ATTACH        |------+
                      | (dwell timer +    |
                      |  hysteresis)      |
                      +-------------------+

The three numbers the docs won’t hand you: how long to wait before declaring terrestrial dead, how much a full PLMN scan costs in time and power, and how re-acquisition behaves after you lose NTN coverage mid-session. Measure all three on your own hardware before you hardcode any timer.

Real-World Gotchas Cellular-Only Firmware Doesn’t Expect

Your cellular-only assumptions about timing are all wrong for NTN.

Latency. NTN round-trip is measured in seconds, not milliseconds, and over GEO carriers it can be much worse. Any retransmit or ACK timer you tuned for terrestrial will fire early and trigger spurious resends. Audit every timeout in your transport and application code and give the NTN path its own budget.

Acquisition windows. Here’s where cellular intuition really breaks. The first NTN attach can take minutes, not the near-instant reconnect you expect on cellular. A heartbeat that assumes a fast connect will stack up retries and drain the battery. Batch what you send and connect on a schedule you can afford.

Doppler and timing advance. LEO satellites move fast, so there’s real Doppler shift and a wide timing advance range that plain cellular never sees. Rel-17 NTN handles the compensation, and the modem abstracts most of it. You mainly feel it as the reason acquisition takes longer, not as something you tune directly.

Power budget. A GNSS fix plus a multi-minute NTN acquisition is one of the most expensive things your device will do. If you’re running from a battery, treat every NTN connect as a costly event and count them. Our battery budgeting notes for low-power devices show the kind of accounting this needs.

Data cost. NTN bytes cost far more than terrestrial ones, so every switching rule that sends you to satellite is a spend decision. Make “stay on cellular if at all possible” the default and reserve NTN for when there’s genuinely no other path.

A Lighter Alternate Path: BLE + Satellite

Before you commit to cellular NTN, know there’s a lighter architecture that reaches orbit without a cellular modem at all.

Instead of the device negotiating an NTN carrier attach, it just broadcasts BLE. Satellites overhead pick up the advertising packets and store-and-forward them to the cloud. Hubble runs this today with 7 satellites in orbit, using the same BLE device SDK and reference firmware you’d use for terrestrial BLE.

The tradeoffs are real. You give up two-way low-latency links and wide payloads; it’s store-and-forward with narrow messages on satellite passes. What you get back is much lower firmware complexity, no PLMN or GNSS-gated attach logic, and a far smaller power draw, since a BLE advertise is cheap next to a multi-minute NTN acquisition.

This is an architecture decision to make up front, not a drop-in swap for NTN. If your data is small, periodic, and one-way (asset location pings, sensor readings from remote sites), BLE-to-satellite can skip most of the complexity this article is about. If you need interactive two-way sessions or larger payloads, you’re back to nRF9151 NTN.

Making the Call and What to Prototype First

Pick the merged nRF9151 dual-mode path when:

  • You need genuine two-way IoT with reasonable payloads in remote areas
  • You already ship on the Nordic nRF91 series and want toolchain continuity
  • Your product can absorb the power and data cost of occasional NTN use
  • You have engineering time for the selection state machine and its timers

Pick BLE + satellite instead when:

  • Your data is small, periodic, and mostly one-way
  • Power budget is tight and store-and-forward latency is acceptable
  • You want satellite reach without cellular NTN cost or firmware complexity

What to prototype first, in order: get a GNSS fix and a bare NTN attach working on real hardware and time it, because that number drives everything else. Then measure a full PLMN scan and a re-acquisition after coverage loss. Only after you have those three measurements should you write the switching policy. Build the state machine around real timings from your bench, never around the ones you assumed.

Feedback note: All AT command references (%XSYSTEMMODE, +CFUN, +CEREG) and NTN acquisition/latency figures must be verified against the current nRF Connect SDK release and Nordic NTN application notes before publish. The article deliberately avoids hard latency/power numbers per the brief’s “do not estimate” instruction, but the “seconds, not milliseconds” and “minutes to attach” claims should be checked against Nordic/Skylo documentation. The battery-budgeting internal link points to the asset-tracking use-case doc as the closest available match; swap for a dedicated low-power guide if one exists.

Hubble Network brings satellite connectivity to devices already built for cellular, without redesigning your RF front end or provisioning a separate radio stack. See how it works →