Cellular IoT · Study deck
Practice: NB-IoT Modem Bring-Up
Picture a parking sensor whose modem sometimes reaches the service and sometimes stops after power-up.
Radio Remi is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Build a safe NB-IoT lab bench for modem bring-up.
- Use generic AT-command checkpoints without assuming every module behaves the same way.
- Capture the records needed for registration, data-path, power-mode, and recovery decisions.
- Separate requested PSM or eDRX settings from network-granted behavior.
Major section
Start With the Story
Repeating a few setup commands until it works creates a demo, but it does not show which state failed or whether the next restart will recover.
- A payload is the useful data carried inside a message.
- The device should stop safely, expose its state, and retry within a stated limit rather than loop forever.
- One bench path cannot promise coverage or battery life in every field site.
Major section
Phoebe's Field Notes: What the Bench Cable Leaves Out of EIRP
The mathematical gist.: A 23.0 dBm radio measured through a 0.500 dB cable reaches the test-set port at 22.5 dBm.
- The same radio with an illustrative -3.00 dBi installed antenna has 20.0 dBm EIRP.
Major section
Overview: Bring-Up Is An Evidence Chain
An NB-IoT modem is not ready because it answers one command or sends one payload from a desk.
- If any part is missing, the result is still a learning record, not a field-pilot approval.
Major section
Practitioner: Build The Bring-Up Record
A reviewer should be able to replay the decision from the records.
- Each gate should have a pass condition and a stop condition.
- The normal run proves the sequence is wired correctly.
- The weak-coverage run shows whether repetitions, registration time, or retries change the energy budget.
Major section
Under the Hood: Requested Timers Are Not Granted Behavior
NB-IoT power behavior depends on both the device request and the network response.
- The modem can request PSM or eDRX, but the operator network decides what it grants, and the whole board still has to enter the expected low-power state.
- Recovery also has hidden state.
- The timer problem has two layers.
Major section
Under the Hood: Requested Timers Are Not Granted Behavior (continued)
In poor conditions, a device may spend more time searching, registering, repeating transmissions, or waiting for a response.
- A modem reset, weak-coverage attach loop, cloud outage, or low-battery restart can turn a successful demo into a battery drain or duplicate-message problem.
- Second, the board may fail to reach the expected low-power state even when the modem does.
- That state machine also needs owner rules.
Major section
Under the Hood: Requested Timers Are Not Granted Behavior (continued)
The application has to know whether a reading was created before or after a reconnect, whether a payload was acknowledged, and whether retrying it would create a duplicate event.
- Regulators, sensors, level shifters, pull-ups, debug interfaces, and host firmware can keep consuming current.
- A credible power result therefore needs both modem readback and whole-board measurement.
- Coverage enhancement and retry behavior are another reason to test the full sequence.
Major section
Implementation Principle
NB-IoT implementation work should be run like an evidence notebook.
- Each lab step should produce a trace, screenshot, modem log, current waveform, or cloud receipt that someone else can review.
- A command returning OK is useful, but it is not enough by itself.
- Hardware Prove the board is safe Confirm supply voltage, peak-current margin, UART voltage levels, antenna connection, and module boot behavior before attaching to a network.
Major section
Generic AT Checkpoints
Modem response: AT Expected evidence: the modem returns a valid response repeatedly after power-up and does not reset under load.
- Expected evidence: the identity is ready for registration, or the lab records the exact provisioning problem.
- Expected evidence: the device reaches an acceptable EPS registration state and the log includes the time needed to get there.
- Expected evidence: the APN or data profile matches the operator, private-network, or platform requirement for the pilot.
Major section
Data Path Validation
The first payload test should be deliberately small.
- A payload ID and timestamps tie these records together.
- This evidence packet connects bring-up to approval: a successful command without server receipt, measured energy, grant readback, or reproducible recovery remains an incomplete result.
Deck summary
Key takeaways
Repeating a few setup commands until it works creates a demo, but it does not show which state failed or whether the next restart will recover.
- The mathematical gist.: A 23.0 dBm radio measured through a 0.500 dB cable reaches the test-set port at 22.5 dBm.
- An NB-IoT modem is not ready because it answers one command or sends one payload from a desk.
- A reviewer should be able to replay the decision from the records.
- NB-IoT power behavior depends on both the device request and the network response.
Retrieval practice
Recall check 1 of 3
Radio Remi says: answer from memory, then check your reasoning.
Q1This NB-IoT lab warns against approving a module from its requested (configured) power-saving timers. Why?
Show answer
Answer: A NB-IoT timers are requested by the device but granted by the network, so measured power-state behavior must be verified.
Retrieval practice
Recall check 2 of 3
Radio Remi says: answer from memory, then check your reasoning.
Q2A prototype sends one NB-IoT payload successfully from the lab bench. What is the best next record set to collect before approving a field pilot?
Show answer
Answer: C A single successful payload is only one checkpoint.
Retrieval practice
Recall check 3 of 3
Radio Remi says: answer from memory, then check your reasoning.
Q3Place each NB-IoT bring-up step where it lives so you can diagnose whether a failure is local, network-side, or operational.
Show answer
Answer: A Place local readiness, service proof, and operational evidence correctly so you can isolate NB-IoT faults without guessing across boundaries.
Q4Complete the implementation gate that decides whether a prototype is ready for field pilot.
Show answer
Answer: A Field pilot readiness requires saved modem evidence, verified network-granted power-mode behavior, and passed recovery tests.
Print reference
Answers
Answer key.
- A · NB-IoT timers are requested by the device but granted by the network, so measured power-state behavior must be verified.
- C · A single successful payload is only one checkpoint.
- A · Place local readiness, service proof, and operational evidence correctly so you can isolate NB-IoT faults without guessing across boundaries.
- A · Field pilot readiness requires saved modem evidence, verified network-granted power-mode behavior, and passed recovery tests.