8  Lab: Cellular Modem Bring-Up

Keywords

cellular modem lab, AT command bring-up, IoT modem registration, cellular IoT lab evidence, modem troubleshooting

8.1 Start With the Wireless Story

Treat modem bring-up as a custody trail. The device must show SIM state, network registration, signal quality, attach behavior, data service, power draw, and failure notes before a successful AT command session can be trusted as deployment evidence.

8.2 In 60 Seconds

A cellular modem lab should prove one layer at a time. Do not start with cloud publishing, sockets, or application code. First prove that the modem is powered, the serial link works, the SIM or profile is usable, signal is present, network registration completes, and a data context can be created when the selected module and network support it.

The useful lab output is an evidence packet:

• modem identity, firmware, SIM or profile state, and region/operator context
• exact command transcript for the bring-up sequence
• signal and registration observations from representative locations
• power-rail or reset observations during attach and transmit attempts
• failure notes with the layer that failed and the next action
• retest triggers after antenna, SIM, firmware, power, enclosure, or location changes

The lab is successful when it explains what was proven, what was not proven, and what evidence is needed before production use.

Phoebe’s Field Notes: What “Correctly Matched” Costs in Decibels

Phoebe’s Why

This lab’s Power and Antenna Evidence step asks whether the antenna is “connected, correctly matched, and placed away from obvious blockers” – three separate physical questions wearing one bullet point. An antenna that is not impedance-matched to its feed line does not simply radiate a little less; part of the signal it’s fed bounces straight back down the cable instead of leaving as a wave, the same way a wave in a rope partly reflects at any point where the rope’s properties change. That reflected fraction never reaches the tower on transmit, and never reaches the modem’s receiver on the way in – which is exactly the kind of loss a bring-up lab can misdiagnose as “weak coverage” when it is really a connector, cable, or detuned-antenna problem sitting between the radio and the air.

The Derivation

A load impedance \(Z_L\) feeding a line of impedance \(Z_0\) reflects a fraction of the wave set by the reflection coefficient:

\[\Gamma = \frac{Z_L-Z_0}{Z_L+Z_0}, \qquad \mathrm{VSWR} = \frac{1+|\Gamma|}{1-|\Gamma|}\]

Return loss expresses the same reflection in decibels:

\[RL_{dB} = -20\log_{10}|\Gamma|\]

Since \(|\Gamma|^2\) is the reflected power fraction, \(1-|\Gamma|^2\) is the fraction actually delivered, so the one-way mismatch loss is:

\[\mathrm{Mismatch\ Loss}_{dB} = -10\log_{10}\!\left(1-|\Gamma|^2\right)\]

Worked Numbers: From VSWR to This Lab’s Own dBm Scale

• A borderline “acceptable” match, VSWR 2:1 (a plausible result for an antenna that is connected but poorly placed): \(\Gamma=(2-1)/(2+1)=0.333\), return loss \(=9.54\) dB, mismatch loss \(=-10\log_{10}(1-0.333^2)=0.512\) dB – small, and easy to overlook on the bench.
• A badly detuned antenna, VSWR 5:1 (catalog-typical for an antenna crowded by a battery, metal bracket, or sealed enclosure – exactly this lab’s own “enclosure detuning” concern): \(\Gamma=(5-1)/(5+1)=0.667\), return loss \(=3.52\) dB, mismatch loss \(=2.55\) dB.
• Reading that delta on this lab’s own signal scale: the companion audit for this chapter already pins down the +CESQ RSRP index as dBm = index - 141, i.e. exactly 1 dB per index step. The \(2.55-0.512=2.04\) dB difference between a merely acceptable match and a badly detuned one is therefore worth about two full RSRP index steps – plausibly the entire margin between a registered modem and one stuck reporting the searching state this lab’s own “Worked Review: Searching But Signal Present” describes.
• The limiting case is the checklist’s own “is the antenna connected” question: as \(Z_L\) approaches an open or short circuit, \(|\Gamma|\to1\) and the mismatch loss grows without bound – essentially all fed power reflects. A disconnected or badly damaged antenna is not a small dB penalty on top of everything else in this derivation; it is the same physics taken to its limit, which is why that check comes before any signal-quality reading is trusted.

8.3 Learning Objectives

By the end of this lab, you will be able to:

• run a cellular modem bring-up sequence without skipping dependency checks
• read AT-command responses as evidence for serial, SIM, signal, registration, and data readiness
• separate UART, SIM, antenna, coverage, power, registration, and data-session failures
• capture a compact lab record that another reviewer can repeat
• identify when a modem result is a hardware, configuration, network, or site problem
• define retest triggers for modem firmware, antenna, power, SIM/profile, and location changes

Quick Check: Cellular Modem Lab

8.4 Lab Scope

This lab is about bring-up evidence. It is not a vendor-specific command reference and it is not a full production firmware tutorial.

Use the command names as patterns, not as a promise that every modem uses the same syntax. Most cellular modules support basic AT-style commands, but data-session, socket, power-saving, and diagnostic commands vary by module, firmware, network, and service type.

The lab should stay bounded to:

• modem responsiveness over the serial link
• SIM, eSIM, or profile readiness
• signal and antenna observations
• registration state and operator context
• packet-service or data-context readiness
• power stability and reset behavior during active modem work
• a record of failures and retest needs

If these checks are not clean, higher-level MQTT, HTTP, TLS, or cloud debugging will waste time.

8.5 Bring-Up Evidence Flow

Figure 8.1: Cellular modem bring-up evidence flow.

Use Figure 8.1 as the lab route. Each step should either produce evidence or stop with a clear failure note.

8.6 Equipment And Setup

Use hardware that lets you observe the modem directly:

• cellular modem module or development board
• compatible antenna for the target band
• SIM, eSIM, or test profile with known service status
• stable power supply sized for modem activity, not only MCU idle current
• USB-to-UART adapter, MCU serial bridge, or terminal connection
• module documentation for command syntax and status meanings
• notebook or log file for command transcripts and observations

Before sending commands, record:

• module model, firmware version if available, and configured radio access technology
• antenna type and connection state
• SIM/profile identifier state without exposing secrets
• region, operator, and expected service type
• power source, cable, regulator, and any bulk capacitance or battery support
• test location and whether it is indoor, outdoor, shielded, or near known interference

Do not publish private identifiers, SIM numbers, keys, APNs, or credentials in learner-facing records.

8.7 AT Command Evidence

The bring-up sequence should prove dependencies in order:

1. Send a basic attention command and confirm the modem answers.
2. Check SIM or profile readiness.
3. Query signal quality and record the response as a relative indicator.
4. Query registration state for the access technology in use.
5. Check packet-service attach or data-context readiness when applicable.
6. Configure the APN or data profile only after the lower layers have evidence.
7. Attempt a bounded data operation only after registration and data context are clean.

Example transcript shape:

TX  AT
RX  OK

TX  AT+CPIN?
RX  +CPIN: READY
RX  OK

TX  AT+CSQ
RX  +CSQ: <rssi>,<ber>
RX  OK

TX  AT+CEREG?
RX  +CEREG: <mode>,<status>
RX  OK

Use the module manual to interpret exact values. The lab record should explain what the response means for this module and network, not just paste the transcript.

8.8 Registration State Review

Registration is a state, not a single instant. A modem may respond to commands, have a valid SIM, and still be searching for a network.

Review questions:

• Is the command checking the right registration domain for the selected service?
• Does the response mean home registration, roaming registration, searching, denied, or unknown?
• Did the lab wait long enough for the module and network state to settle?
• Is denial linked to SIM/profile status, operator restriction, unsupported band, missing service, or weak coverage?
• Is the device allowed to roam for the intended use case?
• Does the record include the location and antenna state where registration was observed?

Do not treat a transient searching state as success. Do not treat one clean registration near a window as proof for the final enclosure or installation location.

8.9 Power And Antenna Evidence

Cellular modems can fail during active network work even when the serial interface appears healthy. Attach, registration, and transmit attempts can expose weak power supplies, poor cables, antenna mismatch, enclosure detuning, or coverage limits.

Record:

• whether the modem resets, disappears from serial, or returns unexpected errors during attach or data attempts
• whether failures correlate with weak signal, indoor location, antenna movement, or transmit attempts
• whether the power source is shared with the MCU and other loads
• whether the antenna is connected, correctly matched, and placed away from obvious blockers
• whether the final enclosure changes signal or reset behavior

The lab does not need a large power-design calculation. It does need evidence that the modem remains stable during the operations being claimed.

8.10 Troubleshooting Map

Figure 8.2: Cellular modem lab troubleshooting map.

Use Figure 8.2 when the lab fails. The point is to isolate the failing layer before changing random settings.

8.11 Lab Record Template

Keep the lab record compact and repeatable:

• Question: What modem behavior is being proven?
• Hardware: module, firmware, antenna, power source, SIM/profile state, enclosure
• Location: region, operator context, indoor/outdoor position, gateway or cell environment notes
• Command transcript: exact commands and responses for each bring-up step
• Observed state: serial, SIM/profile, signal, registration, attach/context, data attempt
• Power and antenna notes: resets, rail observations, antenna placement, enclosure effects
• Decision: pass, provisional, blocked, or redesign
• Retest triggers: firmware, SIM/profile, antenna, power, enclosure, operator, or location change

Screenshots are useful, but text transcripts are easier to review and diff over time.

8.12 Worked Review: Searching But Signal Present

Prompt: “The modem has signal, so the lab is complete.”

Evidence:

• serial command returns are clean
• SIM/profile state is ready
• signal command returns a nonzero response
• registration response reports a searching state
• no data context was created

Review path:

1. Confirm that the registration command matches the selected cellular service.
2. Wait and re-query registration with timestamped observations.
3. Check antenna placement, supported bands, operator/service profile, and location.
4. Move to a known-coverage location or compare with a reference device if available.
5. Record whether the issue is coverage, service authorization, band support, or configuration.

Accepted answer: “Signal presence is not registration. The lab remains provisional until registration and data-context evidence are captured.”

8.13 Worked Review: Data Attempt Resets The Modem

Prompt: “The application code is broken because the modem resets when it sends data.”

Evidence:

• basic AT command response is clean
• SIM/profile and registration checks pass
• reset occurs when attach, context activation, or data send begins
• failure is worse in weak-signal locations

Review path:

1. Separate application logic from modem stability by repeating a minimal command sequence.
2. Observe whether the modem resets, drops serial, or reports a recoverable error.
3. Check power source, cable, regulator headroom, connector quality, antenna, and enclosure.
4. Compare behavior in stronger and weaker coverage locations.
5. Record whether the fix belongs to power design, antenna placement, retry behavior, or firmware.

Accepted answer: “A reset during active modem work is often a power, antenna, or coverage evidence problem before it is an application-code problem.”

8.14 Common Mistakes

• starting with MQTT, HTTP, or cloud tests before proving registration
• treating one OK response as proof that the modem is ready for data
• ignoring SIM/profile readiness or service activation state
• reading signal quality without checking registration state
• using a lab antenna or open bench result as final enclosure evidence
• assuming all vendors use the same data-session AT commands
• hiding command transcripts behind screenshots that cannot be searched
• leaving secrets, SIM identifiers, APNs, or credentials in shared lab records
• ignoring resets during attach or transmit attempts
• failing to record retest triggers after firmware, SIM/profile, antenna, power, or site changes

8.15 Knowledge Check: Cellular Modem Bring-Up

8.16 Match The Check To The Evidence Layer

8.17 Order The Cellular Modem Lab

8.18 Review Checklist

Before accepting the cellular modem lab, confirm that the record includes:

• module, firmware, antenna, power source, SIM/profile state, and location
• exact AT-command transcript for serial, SIM/profile, signal, registration, and data-context checks
• interpretation of registration state for the selected service
• antenna and enclosure observations from the tested configuration
• power stability observations during registration and data attempts
• failure layer, next action, and retest evidence if any step failed
• redaction of secrets, private identifiers, APNs, credentials, and account data
• retest triggers after firmware, antenna, power, SIM/profile, operator, enclosure, or site changes

8.19 A Cellular Modem Is an AT-Command Peripheral

A cellular IoT module — a u-blox SARA, Quectel BG96, or similar — behaves like a serial peripheral driven by AT commands over a UART. Bring-up is a fixed sequence: power the radio on, unlock the SIM, tell it the network access point, wait for it to register, and read the signal before sending anything.

The registration step is where NB-IoT and LTE-M devices differ from a phone only in the commands used (AT+CEREG? for EPS/LTE registration rather than AT+CREG? for legacy). Once registered, the module can open a data context and transmit; before that, application traffic simply fails.

Worked bring-up check. A reviewer should be able to read the transcript and identify the exact layer that passed. AT followed by OK proves the host serial path and command parser. AT+CPIN? returning READY proves the SIM or profile is usable enough for registration. AT+CESQ or the module’s equivalent gives a signal observation tied to antenna and location. AT+CEREG? returning a registered state proves network registration for the selected LTE/EPS service. Only after those checks should the lab configure or activate a data context.

If the sequence stops, record the stop as the result instead of skipping ahead. A clean serial response plus +CPIN: READY and +CEREG: 0,2 is not a failed application; it is a registration-layer problem. The next evidence should be antenna placement, supported bands, service authorization, roaming permission, location, and elapsed wait time. A lab that preserves that boundary is useful because another engineer can repeat the same layer check without inheriting a vague “cloud publish failed” report.

Bring-up in order: radio on → SIM ready → APN set → registered → read signal → send. Skip a step and the modem looks “broken” when it is only unregistered.

8.19.1 Overview Knowledge Check

8.20 The Bring-Up Sequence and Reading Signal

A minimal, ordered bring-up:

Step	Command	Checks
Radio on	AT+CFUN=1	Full functionality enabled
SIM	AT+CPIN?	Returns READY
APN	AT+CGDCONT=1,"IP","<apn>"	Data context defined
Registration	AT+CEREG?	Status 1 (home) or 5 (roaming)
Signal	AT+CESQ	Reads RSRQ and RSRP

Signal is best read with AT+CESQ, whose last two fields are RSRQ and RSRP as indices: the RSRP index 0–97 maps linearly to roughly −141 dBm up to −44 dBm, and 255 means “unknown.” (The older AT+CSQ only returns a coarse RSSI index 0–31.)

Worked example. A device reports +CEREG: 0,2 — status 2 means “searching, not yet registered,” so any socket open will fail. The fix is not in the application: check the APN, band configuration, and antenna, then poll AT+CEREG? until it reads 1 or 5, and only then read AT+CESQ to confirm usable RSRP before transmitting.

A compact lab table can prevent false conclusions. Record the command, response, interpretation, and next action. For example, AT+CPIN? returning READY means “SIM/profile not blocking this step”; it does not mean “network available.” AT+CESQ returning unknown signal fields means the antenna, band, modem state, or registration stage still needs investigation. AT+CEREG? returning a denied state points toward service authorization, region, operator selection, or supported-band mismatch rather than UART wiring.

Also record the physical state during the command sequence. A modem that answers AT on bench power but disappears from serial during registration may be exposing a power rail, cable, or antenna problem. Repeat the minimal sequence in a stronger-coverage location and with the final enclosure connected. If the reset disappears outdoors or with a known-good antenna, the lab has found a propagation or antenna path; if it disappears with a stronger supply, the lab has found a power-design path. Keep those conclusions separate from application code.

8.20.1 Practitioner Knowledge Check

8.21 PSM and eDRX Power-Saving Timers

Battery life on cellular IoT comes from two negotiated sleep modes. PSM (Power Saving Mode) lets the modem power down almost completely while staying registered. The device requests two timers at attach or tracking-area update: T3324, the Active Timer, sets how long it stays reachable after going idle; T3412, the extended periodic-TAU timer, sets how long it may sleep before it must check in (encodable up to hundreds of days). During PSM the device is unreachable for downlink until it wakes to send or to run its periodic TAU.

eDRX (extended Discontinuous Reception) is the middle option: the device sleeps but wakes on a long, agreed cycle to listen for paging — up to about 43.7 minutes for LTE-M and 2.9 hours for NB-IoT. eDRX keeps the device occasionally reachable at the cost of some standby current; PSM saves more but makes downlink latency as long as the sleep interval.

Worked example. A meter that only ever reports uses PSM: enable it with AT+CPSMS, request a short T3324 (stay awake ~10 s after sending in case of a reply) and a long T3412 (sleep an hour between periodic check-ins), and average current drops toward the microamp range. A device that must occasionally receive a command instead uses eDRX so the network can page it within one cycle. The choice is a reachability-versus-battery decision, set by these timers.

The lab should not claim battery behavior just because a command was accepted. A modem can accept a PSM request and receive a different timer from the network, or the network can reject the requested mode. The transcript should capture the request, the modem’s reported negotiated settings if the module exposes them, and the observed current or wake behavior at a coarse level. If the device stays reachable for a short active window and then becomes unavailable until the next uplink or tracking-area update, the observed behavior matches the PSM claim.

Power-saving evidence also belongs with registration evidence. A device that drops registration every cycle may spend more energy reattaching than it saves in sleep. A device that needs downlink control within minutes may fail the product requirement if PSM sleeps for an hour. The bring-up lab should therefore record the chosen mode, requested timers, observed reachability, wake cause, and the retest triggers: operator profile change, firmware update, SIM/profile change, antenna/enclosure change, or deployment region change.

8.21.1 Under-the-Hood Knowledge Check

8.22 Summary

A cellular modem bring-up lab should prove the modem stack one layer at a time: serial response, SIM or profile readiness, signal, registration, packet-service context, and bounded data readiness. The important artifact is not a large code sample. It is a clear evidence record that shows what worked, what failed, what layer failed, and what must be retested when hardware, firmware, service, antenna, power, or location changes.

8.23 Key Takeaway

Lab: Cellular Modem Bring-Up should produce deployment evidence for spectrum assumptions, coverage, antenna placement, link budget, modem behavior, fallback paths, and validation limits.

8.24 Concept Relationships

• Cellular spectrum explains why supported bands, operator service, and region matter before the lab starts.
• Propagation design explains why antenna placement, enclosure, location, and coverage affect modem results.
• Coverage planning labs extend modem observations into deployment mapping and acceptance records.
• Wi-Fi spectrum labs use similar evidence discipline for a different radio environment.
• Mobile wireless review compares cellular modem evidence against other wireless technology options.

8.25 What’s Next

• Cellular Spectrum for IoT reviews cellular band and operator context.
• Wireless Propagation and Design explains the coverage and antenna evidence behind modem lab results.
• Mobile Labs: Coverage Planning extends signal and registration evidence into deployment planning.
• Mobile Labs: Wi-Fi Spectrum Analysis practices similar RF evidence gathering in shared Wi-Fi spectrum.
• Mobile Wireless Comprehensive Review compares cellular modem trade-offs with other wireless options.