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.
- The 2.50 dB gap is a 1.78× bench-to-radiated power ratio, so a conducted pass does not prove installed coverage.
- Cable calibration, antenna pattern, mismatch, enclosure state, network path, and uncertainty must stay in the test record.
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.
- A desk near a window, a developer SIM, an open enclosure, or a powered USB bench can hide the failures that appear when the antenna moves inside the final housing or when weak coverage triggers repeated attach attempts.
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
Simulation-First Dry Run
The dry run is not a substitute for RF testing; it prevents the lab from hiding missing assumptions.
- This run printed BOOT, CELL_SEARCH, ATTACH_REQUEST, REGISTERED, UPLINK_REPORT, NETWORK_GRANTED_TIMER_CHECK, PSM_SLEEP_OR_EDRX_PAGING, and WAKE_AND_REPEAT.
- The local output is a state-model replay only.
- It did not perform radio attach, grant negotiation, sleep-current measurement, or cloud delivery.
Try it: Simulation-First Dry Run in the chapter
Major section
Generic AT Checkpoints
Expected evidence: the identity is ready for registration, or the lab records the exact provisioning problem.
- In the terminal, send AT repeatedly after boot and save its timestamped response; an intermittent reply points back to power, UART, or reset behavior.
- No modem AT commands were issued in this lane; use your module's command manual for syntax and timeouts.
- Expected evidence: the device reaches an acceptable EPS registration state and the log includes the time needed to get there.
Major section
Data Path Validation
The first payload test should be deliberately small.
- In the modem terminal, send a short payload with a unique ID and log the request, response, timestamp, and registration state.
- In the cloud endpoint, find the same ID and server timestamp; a modem OK without this receipt is incomplete.
- A payload ID and timestamps tie these records together.
Major section
Recovery Tests
Recovery is where many prototypes fail.
- On recovery, compare the delivered payload ID with the queue record and prove that duplicate processing is suppressed.
- No reset, attenuation, cloud outage, or battery test was performed here; the four fault cards below define the on-hardware observations.
- Fault Cloud unavailable Block the endpoint or reject the application request.
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 4
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: D 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 4
Radio Remi says: answer from memory, then check your reasoning.
Q2A lab script works on one NB-IoT modem but not another. What should the engineer check first?
Show answer
Answer: C Generic checkpoints still need vendor-specific command validation.
Retrieval practice
Recall check 3 of 4
Radio Remi says: answer from memory, then check your reasoning.
Q3A 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: D A single successful payload is only one checkpoint.
Q4What checks power, antenna, UART levels and current measurement before modem testing?
Show answer
Answer: C Stable power, antenna, UART levels, and current measurement make every later observation trustworthy.
Retrieval practice
Recall check 4 of 4
Radio Remi says: answer from memory, then check your reasoning.
Q5Complete 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.
- D · NB-IoT timers are requested by the device but granted by the network, so measured power-state behavior must be verified.
- C · Generic checkpoints still need vendor-specific command validation.
- D · A single successful payload is only one checkpoint.
- C · Stable power, antenna, UART levels, and current measurement make every later observation trustworthy.
- A · Field pilot readiness requires saved modem evidence, verified network-granted power-mode behavior, and passed recovery tests.