DEV Community

Cover image for Designing Years-Long Asset Trackers on LTE-M/NB-IoT: nRF9160, GNSS, and Real-Time Wake
applekoiot
applekoiot

Posted on

Designing Years-Long Asset Trackers on LTE-M/NB-IoT: nRF9160, GNSS, and Real-Time Wake

"Can a tracker sleep for years yet wake up instantly when I need a live fix?"

That question sits at the heart of asset‑tracking engineering. If you build for logistics—trailers, containers, tools in the field—you've probably discovered that radios, sensors, and firmware state machines are in constant tension with your battery. This post is a practitioner’s guide to resolving that tension on LTE‑M/NB‑IoT using nRF9160, multi‑GNSS, and SMS/eDRX real‑time wake. It’s hands‑on: no marketing, no fluff—just patterns that have worked, mistakes you can avoid, and how to reason about multi‑year operation without giving up responsiveness.

TL;DR: Treat responsiveness as an exception path, not a default behaviour. Push everything else into deterministic sleeps governed by a small set of rules you can explain to operations.

1. Systems thinking before schematics

Start with an operational model, not a PCB. The asset lifecycle dictates your power budget more than any component:

  • Inventory periods: assets sit mostly still; you need a daily or weekly heartbeat.
  • Transit bursts: during dispatch, you need start/stop stamps or dense breadcrumbs.
  • Exception handling: a small fraction of time when you must see live motion now.

Map those to three firmware concepts:

  1. Long‑Standby (heartbeat): wake → fix → transmit → sleep.
  2. Trip (event stamps): movement trigger posts departure; after a static window, post arrival.
  3. Emergency/Activity (dense tracking): elevated report rate for a bounded duration, then fall back.

If you can convince stakeholders that 95 % of time belongs to #1 and #2, you’ve already earned years of battery life.

2. Why nRF9160 (and similar cellular SiPs) are a good fit

The nRF9160 bundles an LTE‑M/NB‑IoT modem, GNSS receiver, PMIC, and a Cortex‑M33 MCU in a single SiP. Three practical advantages matter in the field:

  • Integration reduces leakage paths: fewer rails and level shifters, fewer peripheral always‑on domains.
  • Coordinated sleep: the application core understands the modem’s paging windows (eDRX/PSM), so your scheduler can align GNSS fixes and transmissions with minimal wake overhead.
  • Firmware simplicity: one SDK to rule modem, GNSS, sockets, and FOTA—less glue code, fewer wakeups.

You can absolutely ship with a discrete modem plus a separate MCU, but count the board space and the "surprise milliamps" through level translators and debug circuitry you forgot to gate.

3. Power budgeting without illusion

Primary chemistry (e.g., Li‑MnO₂ at 8000 mAh) buys you safety, shelf stability, and zero maintenance charging. But multi‑year life is still about duty cycle math:

  • Active attach + transmission on LTE‑M: ~150–250 mA for seconds, not minutes.
  • GNSS cold start: tens of seconds; hot start: a handful.
  • Sleep: single‑digit microamps if you’re disciplined.

A useful back‑of‑the‑envelope calculation:

Daily heartbeat (1 fix/day):
GNSS hot start 5 s @ 25 mA   = 0.035 mAh
Tx (Cat M1) 3 s @ 200 mA     = 0.167 mAh
Overhead 2 s @ 10 mA         = 0.006 mAh
Sleep 24 h @ 8 µA            = 0.192 mAh
------------------------------------------------
~0.40 mAh/day → 8000 mAh ≈ 20 000 days? Nope.

Now add reality:
- Sometimes warm/cold starts (10–30 s)
- Retries at coverage edges
- Occasional emergency bursts

Pragmatic target after margins: ~5–6 mAh/day
→ 8000 mAh / 6 ≈ 1333 days ≈ 3.6 years
Enter fullscreen mode Exit fullscreen mode

This is why microarchitectural discipline matters more than spec‑sheet hero numbers.

4. The real‑time wake pattern (SMS + eDRX)

The failure mode of many trackers is polling out of fear. They wake every 5–15 minutes to ask, “anything for me?”—and die in months. Flip it:

  • Keep the modem in eDRX/PSM so it only peeks at the network on extended paging cycles.
  • When operations need a live fix, send a structured SMS (small, carrier‑portable).
  • The device wakes on the next paging window, validates the command, performs a short live window (for example, 60–180 seconds at 10–30‑second intervals), then forces itself back to standby.

Key detail: store a cool‑down timestamp. If a second SMS arrives within N minutes of the last session, either extend the same window or reject the request—otherwise you risk thrash that torpedoes the battery.

Minimal command schema (example)

CMD: WAKE,MODE=EMERGENCY,DUR=180,INT=15,MAXSPD=120
SIG: HMAC‑SHA256(device_id|timestamp|payload, key)
Enter fullscreen mode Exit fullscreen mode

Parse, verify HMAC, check a monotonic clock, then act. If you control the SIM profile, keep MT‑SMS enabled across regions.

Diagram of real-time wake sequence for an LTE-M/NB-IoT asset tracker: sleeping mode with eDRX paging windows, an SMS wake event, multiple GNSS fixes, and LTE-M transmissions during a 120-second emergency session in a warehouse yard.

5. GNSS that respects batteries

GNSS is often the real hog, not the modem. Practical tactics:

  • Prefer hot starts: keep ephemeris warm by scheduling heartbeats under open sky at shift changes.
  • Time‑budget fixes: cap acquisition to, say, 20 seconds; if no fix, fall back to cell‑ID/LBS.
  • Two‑shot reporting: after a cold start, send a quick “coarse” fix immediately, then another point 10–20 seconds later when geometry improves.
  • Motion‑gated GNSS: don’t wake GNSS for a stationary asset unless verifying inventory.

For yard/warehouse installs, antenna placement beats any DSP trick. If you must mount under steel, set expectations that LBS fills the gaps.

6. Firmware state machine you can explain on a whiteboard

Keep it boring. You want three boxes and four arrows, not a spaghetti diagram.

[SLEEP]
  | timer
  v
[HEARTBEAT] → Tx → [SLEEP]

[SLEEP] --motion--> [TRIP_START] → fix → Tx → [SLEEP]
[SLEEP] --static 4 min--> [TRIP_STOP] → fix → Tx → [SLEEP]

[SLEEP] --SMS--> [EMERGENCY] (dense reporting, bounded) → [SLEEP]
Enter fullscreen mode Exit fullscreen mode

Rules of thumb

  • Only one real‑time mode. Don’t fragment into “high,” “higher,” “highest.”
  • Static detection hysteresis: ≥ 4 minutes avoids oscillation on forklifts.
  • All transitions write a reason code to NVM for post‑mortems.

7. Sensor wiring that matters

A cheap 3‑axis accelerometer can be your best battery saver—if you wire interrupts correctly and keep the MCU asleep. Useful channels:

  • Motion → wake for Trip start
  • No‑motion over a window → Trip stop
  • High‑g → impact/crash event (rate‑limit these!)
  • Orientation → optional; sometimes correlates with tamper

If you add a light sensor for anti‑removal, calibrate in situ. Warehouse ambient changes a lot; use deltas, not absolutes.

8. Mechanical realities (magnets vs screws, IP ratings)

Magnets are fantastic for prototypes and serviceability; screws win on high‑vibration assets. Whichever you choose:

  • Don’t place under direct jet‑wash. IP65 resists water jets, not pressure washers at 5 cm.
  • On trailers, tuck behind structural lips. On containers, inside the door rib works well.
  • Add a thin non‑metal shim if magnet saturation is too strong to service.

Temperature: test at −20 °C to +65 °C with real carriers. Cold modems attach slower; budget extra seconds for attach + transmission.

Exploded view of a rugged LTE-M/NB-IoT asset tracker showing the top cover with blue X motif, circuit board with integrated nRF9160, motion sensor and connectors, large primary battery, and magnetic base.

9. Data model and APIs that won’t paint you into a corner

Keep payloads boring and versioned. Example (JSON, but CBOR/Protobuf are fine):

{
  "v": 2,
  "ts": 1737062400,
  "id": "A1C3...",
  "m": "HB|TRIP_START|TRIP_STOP|EMERGENCY",
  "pos": {"lat": 42.36, "lon": -71.05, "src": "GNSS|LBS", "acc": 3.2},
  "spd": 14.2,
  "bat": {"pct": 78},
  "sig": {"rsrp": -96, "rat": "LTE-M"},
  "aux": {"impact": false}
}
Enter fullscreen mode Exit fullscreen mode
  • v lets you evolve payloads without breaking old parsers.
  • m is the single strongest feature for downstream analytics; SOPs can be built on it.
  • Don’t spam the cloud with “I’m still moving” every 2 seconds unless you truly need breadcrumbs.

10. OTA that respects risk

FOTA is non‑negotiable—but ship with a throttle:

  • Window updates to heartbeat slots; never in emergency mode.
  • Stage critical updates by cohort (1 %, then 5 %, 20 %, …).
  • Persist a last‑good firmware bank; roll back on watchdog.

Make sure your cryptography doesn’t assume perfect clocks. Many trackers sleep through time sync; use monotonically increasing counters and per‑device nonces.

11. Security that survives the field

  • Harden SMS: all commands must carry a MAC; reject stale timestamps.
  • SIM policy: lock APNs, disable voice, enable MT‑SMS only where you operate.
  • Rotate keys over the same FOTA pipeline you trust.
  • Privacy: don’t store personally identifiable information on the device; identifiers should be opaque.

12. Deployment playbook (what ops actually do)

  1. Pilot two lanes (one stable, one risky) for two weeks.
  2. Start with: Heartbeat = 24 h; Trip = on; Emergency = 120 s @ 15–30 s intervals.
  3. Collect: attach times, fix times (hot/warm/cold), transmission durations, battery delta/day.
  4. Tune: accelerometer thresholds, static window, retry limits.
  5. Write SOPs: who can trigger Emergency? for how long? what is the cool‑down?
  6. Only after pilots, lock firmware and push FOTA to the fleet.

13. KPIs that actually predict battery life

  • Daily mAh burn (derived): (Δ% × capacity) ÷ days
  • Attach time distribution: median and p95; long tails kill battery
  • GNSS TTFF distribution (hot/warm/cold buckets)
  • Emergency session minutes/week per asset
  • False Trip ratio (movement noise vs real moves)

If you don’t trend these weekly, you’re guessing.

14. Common failure stories (so you don’t repeat them)

  • Periodic polling “just in case.” It’s the fastest way to a warranty return queue.
  • Unbounded emergency. Someone forgets to exit real‑time mode after recovery. Use watchdog timers.
  • Warehouse‑mounted under steel. GNSS never gets first fix; everything looks broken. Move the device 10 cm to daylight and it “magically” works.
  • Debug UART left alive. That rogue LED and FTDI rail are eating your sleep budget—gate them.
  • No hysteresis. Vibrations toggle your state machine; you die by a thousand interrupts.

15. Example test protocol (week one)

  • Days 1–2: Heartbeat only; measure attach + transmission + sleep currents with a DMM and a shunt (log to CSV).
  • Days 3–4: Trip mode; move assets 1–2 times/day; confirm start/stop stamps match ground truth.
  • Day 5: Emergency drills; trigger three short sessions across different carriers.
  • Days 6–7: Cold‑start tests after 24 h indoors; record TTFF distributions.

Automate logs; don’t rely on hand notes. If a fix takes 35 s on one carrier band and 8 s on another, you want that data visible for SIM procurement.

16. Final checklist before you ship

  • [ ] Current draw validated with real carriers at temperature edges
  • [ ] SMS command MAC verified with key rotation
  • [ ] FOTA rollback tested (pull the plug mid‑update)
  • [ ] Accelerometer thresholds tuned on worst‑case assets
  • [ ] Static window set (≥ 4 min) and documented
  • [ ] SOP for emergency duration + cool‑down
  • [ ] Payload schema versioned and monitored

Closing thoughts

Multi‑year trackers are less about “the biggest battery” and more about choosing when not to be awake. If you can keep your design to a small, explainable state machine; align GNSS and LTE‑M around paging windows; and treat live tracking as an exception, you’ll find that “years” stops being a slogan and becomes a measurable property of your fleet.

Top comments (0)