This chapter series provides hands-on labs for wireless IoT analysis: cellular modem integration using AT commands, Wi-Fi spectrum analysis with ESP32 channel scanners, and RF coverage planning with Python tools. These labs transform theoretical concepts like path loss and channel congestion into practical skills you can apply to real deployments.
12.1 Learning Objectives
By the end of these labs and implementation chapters, you will be able to:
Conduct an RF site survey: Operate Wi-Fi scanners (and optional SDR tools) to classify interference sources and quantify congestion levels
Evaluate and select optimal Wi-Fi channels: Analyze scan results to rank non-overlapping channels and justify a channel plan based on measured RSSI and network density
Construct an ESP32 channel scanner: Design and implement firmware that inventories nearby networks and generates channel-occupancy visualizations
Interpret signal quality measurements: Collect RSSI-versus-distance data and differentiate real-world deviations from theoretical free-space path loss models
Commission a cellular modem: Execute the AT command bring-up sequence to verify power, SIM readiness, network registration, and signal quality on LTE-M or NB-IoT
Synthesize a site-survey report: Compile measurements, heatmaps, and link-budget calculations into actionable deployment recommendations covering channel selection, AP placement, and risk mitigation
12.2 Prerequisites
Before diving into these chapters, you should be familiar with:
Mobile Wireless: Fundamentals: Understanding electromagnetic waves, frequency bands, path loss calculations, and spectrum allocation is essential for interpreting lab results
Mobile Wireless Technologies Basics: Knowledge of wireless communication principles, frequency characteristics, and propagation models provides the theoretical foundation for practical measurements
Networking Basics for IoT: Basic networking concepts help in understanding how wireless technologies integrate into larger IoT systems
Basic programming skills: Familiarity with Python and C++ (Arduino/ESP32) is needed to implement the lab exercises and analyze data
For Beginners: How to Use These Mobile Wireless Labs
These labs are about making the RF concepts from the fundamentals chapters visible in the real world.
Putting Numbers to It
Path loss follows \(\text{FSPL(dB)} = 20\log_{10}(d) + 20\log_{10}(f) + 32.45\) where \(d\) = km, \(f\) = MHz. Worked example: At 30m (0.03 km) and 2.4 GHz, FSPL = 20log₁₀(0.03) + 20log₁₀(2400) + 32.45 = -30.46 + 67.60 + 32.45 = 69.6 dB. Adding 3 concrete walls (12.5 dB each) gives total loss 69.6 + 37.5 = 107 dB—requiring +7 dBm transmit power to reach -100 dBm sensitivity.
If you have an ESP32 and can install tools:
Run the Wi-Fi scanner, collect RSSI measurements at different locations, and build a simple channel plan.
Use the exercises to connect what you see on the screen with ideas like channel congestion and path loss.
If you also have a cellular modem module:
Do the AT command smoke test (power, SIM readiness, registration, signal quality) before writing firmware.
If you cannot run the code right now:
Read through the sketches and focus on the printed outputs and analysis questions.
Sketch simple “coverage maps” on paper based on the example outputs, then answer the Knowledge Check.
Key ideas to remember while working through these chapters:
Concept
Plain explanation
Channel
A slice of spectrum; multiple Wi-Fi networks share it
RSSI
Received signal strength indicator (how loud the AP is)
Interference
Other devices transmitting on the same/adjacent channel
Path loss
How much signal power is lost as distance increases
If terms like RSSI, path loss, or channel overlap feel unfamiliar, skim Mobile Wireless Fundamentals and Mobile Wireless Technologies Basics again, then come back and treat these labs as concrete experiments that bring those graphs and formulas to life.
12.4 Chapter Overview
This content has been organized into three focused chapters for easier navigation and deeper coverage of each topic:
ESP32 real-time spectrum monitor with web interface
RF coverage planner with RSSI heatmaps
Dead zone identification and AP placement optimization
Best for: Pre-deployment planning, quantitative link analysis, and building monitoring tools.
Sensor Squad: Lab Adventures Ahead!
Sammy Sensor: “Labs are where the real fun begins! Instead of just reading about radio waves, you get to build your own tools to see them. An ESP32 Wi-Fi scanner is like giving yourself superhero vision for invisible signals!”
Lila the Light Sensor: “The cellular modem lab is like learning to talk to a phone network using a secret language called AT commands. You type special words, and the modem tells you about signal strength and which tower it is connected to!”
Max the Motion Detector: “My favorite part is the coverage planning lab. You can create heat maps that show where signals are strong (red and hot) and where they disappear (blue and cold). It is like making a treasure map for radio waves!”
Bella the Button: “Even if you do not have the hardware right now, read through the code and outputs. Understanding what these tools produce is almost as valuable as running them yourself!”
12.5 Knowledge Check
Q1: An ESP32 Wi-Fi scan reveals 12 networks on channel 6, 4 on channel 1, and 7 on channel 11. Which non-overlapping channel should you select for a new IoT access point?
Channel 6 – most networks means best infrastructure
Channel 1 – fewest networks means least congestion
Channel 3 – between channels 1 and 6
Channel 13 – highest available channel number
Answer
B) – Channel 1 has only 4 networks compared to 12 on channel 6 and 7 on channel 11, making it the least congested non-overlapping channel. Channel 3 would overlap with both 1 and 6 (Wi-Fi channels are 22 MHz wide). Channel 13 is restricted or unavailable in some regions.
12.6 Knowledge Check
Q2: When bringing up a cellular modem, what is the correct sequence of AT command checks?
Signal quality -> SIM status -> Power on -> Network registration
Power on -> SIM status -> Network registration -> Signal quality
Network registration -> Power on -> Signal quality -> SIM status
SIM status -> Power on -> Network registration -> Signal quality
Answer
B) – The correct modem bring-up sequence is: (1) Power on and verify communication (AT -> OK), (2) Check SIM status (AT+CPIN?), (3) Verify network registration (AT+CREG? or AT+CEREG?), and (4) Check signal quality (AT+CSQ). Each step depends on the previous one succeeding.
12.7 Recommended Learning Path
For complete understanding: Work through all three chapters in order.
Q3: You calculate a free-space path loss of 70 dB for a 30-meter indoor link at 2.4 GHz. Your transmitter outputs +20 dBm with a 2 dBi antenna, and there are two concrete walls in the path. Assuming 12.5 dB loss per wall, a 0 dBi receiver antenna, and a receiver sensitivity of -85 dBm, will the link close?
Yes – with about 12 dB of margin, making it a reliable link
No – the total loss exceeds the link budget and the signal will not reach the receiver
Yes – but the margin is under 20 dB, so it may degrade under multipath fading or temporal interference
Cannot determine without knowing the modulation scheme
Answer
C) – Total path loss = 70 dB (FSPL) + 25 dB (2 walls x 12.5 dB) = 95 dB. Received power = +20 dBm (TX) + 2 dBi (TX antenna) + 0 dBi (RX antenna) - 95 dB (loss) = -73 dBm. This is above the -85 dBm sensitivity, giving 12 dB of link margin. While 12 dB is sufficient for a static, line-of-sight scenario, indoor environments introduce multipath fading (up to 10-15 dB fluctuation), people moving through the path, and time-varying interference from microwaves or neighboring Wi-Fi. A robust deployment typically targets 20+ dB of margin. With only 12 dB, the link will work most of the time but may experience intermittent drops, so option (a) oversimplifies the real-world behavior.
Common Mistake: Deploying IoT Without a Cellular Modem Smoke Test
The Mistake: Engineers order 500 NB-IoT modems, solder them to production PCBs, and deploy them to the field—only to discover that 30% fail to register on the network due to APN misconfiguration, wrong frequency bands, or SIM activation issues.
Why It Happens:
Time pressure: “We tested one unit, it worked, ship the rest!”
Assumption: “All cellular modems work the same way”
Documentation gaps: APN settings buried in carrier portals, not in modem datasheets
Carrier variations: Different carriers use different bands, APNs, and authentication methods
Real-World Example: A smart meter company deployed 1,000 NB-IoT devices across Europe. In Germany, devices worked perfectly. In Italy, 40% couldn’t register because: - German carrier used Band 8 (900 MHz) - Italian carrier used Band 20 (800 MHz) - Modems were single-band (Band 8 only) - Cost: €50,000 in field recalls and modem replacements
The Smoke Test (5-Minute Validation):
Before ANY production deployment, run this AT command sequence on EVERY modem model and carrier combination:
# 1. Power on and verify communicationATResponse: OK ← Basic communication works# 2. Check IMEI and firmware versionAT+CGMMResponse: BG95-M3 ← Modem modelAT+CGMRResponse: BG95M3LAR02A02 ← Firmware version# 3. Check SIM statusAT+CPIN?Response: +CPIN: READY ← SIM inserted and not locked# If CPIN: SIM PIN, you need to unlock with AT+CPIN=1234# 4. Check signal qualityAT+CSQResponse: +CSQ: 22,99 ← 22 = -69 dBm (good signal)# Scale: 0-9=poor, 10-19=marginal, 20-31=good# 5. Check network registration (NB-IoT)AT+CEREG?Response: +CEREG: 0,1 ← 1=registered, 5=roaming# 0=not registered, 2=searching, 3=denied, 4=unknown# 6. Verify operatorAT+COPS?Response: +COPS: 0,0,"Vodafone",9 ← 9=LTE mode# 7. Check assigned IP addressAT+CGPADDR=1Response: +CGPADDR: 1,"10.123.45.67" ← IP assigned by carrier# 8. Verify frequency band (critical for multi-region)AT+QNWINFOResponse: +QNWINFO: "NB-IOT","26201","LTE BAND 20",6400# Band 20 = 800 MHz (common in EU)# 9. Test DNS resolutionAT+QIDNSGIP=1,"google.com"Response: +QIURC: "dnsgip","142.250.185.78" ← DNS works# 10. Test MQTT connection (application-level validation)AT+QMTOPEN=0,"test.mosquitto.org",1883Response: +QMTOPEN: 0,0 ← 0=success
What Each Test Catches:
Test
Failure Mode Detected
Impact if Skipped
CPIN
SIM not inserted, locked, or expired
100% connection failure
CSQ
No antenna, poor coverage
Intermittent dropouts
CEREG
Wrong APN, band mismatch, no subscription
No network access
COPS
Wrong carrier, roaming disabled
Roaming charges or no service
CGPADDR
APN misconfiguration, no data plan
Can register but no IP connectivity
QNWINFO
Wrong frequency band for region
Works in lab, fails in field
DNS
Firewall blocking port 53, carrier DNS issues
MQTT/HTTP fail silently
MQTT
TLS issues, broker authentication problems
Application-layer failure
The 3-Stage Testing Protocol:
Stage 1: Lab Bench (100% of units)
Test with carrier-provided SIM
Verify all 10 AT commands
Measure current draw during: idle, attach, transmit, PSM
Test antenna VSWR (voltage standing wave ratio)
Stage 2: Pilot Deployment (10 units, 7 days)
Deploy in actual coverage areas
Monitor daily: CSQ, CEREG state, data throughput
Test during: rain, night, weekends (carrier load varies)
Collect failure modes: timeouts, rejections, band changes
Stage 3: Production Batch Sample (1% of shipment)
Test first production run before mass deployment
Verify no supply chain substitutions (modem, antenna, SIM batch)
Run 72-hour stress test (continuous connect/disconnect)
Cost-Benefit Math:
Scenario: 1,000 NB-IoT devices, $50/device
Approach
Testing Cost
Field Failure Rate
Recall Cost
Total Cost
No testing
$0
30% (300 units)
$15,000 (labor + shipping)
$15,000
Smoke test
$500 (10 hours × $50/hr)
5% (50 units)
$2,500
$3,000
Full protocol
$2,000 (pilot + sampling)
1% (10 units)
$500
$2,500
Savings: $12,500 (83% reduction in field failures)
Key Insight: The 5-minute smoke test has a 30:1 ROI. Spending 10 hours upfront testing prevents 150 hours of field troubleshooting. The most expensive bug is the one found by customers in production.
Common Pitfalls
1. Skipping Error Handling in Lab Implementation Code
Lab code that assumes perfect conditions (always connected, no transmission errors) fails when deployed. Every network operation — connection, transmission, reception — can fail. Implement error handling, timeout detection, and retry logic from the start, even in lab prototypes.
2. Not Measuring Actual vs Expected Performance in Labs
Lab exercises should always include a prediction step before measurement. Predict the expected RSSI, throughput, or latency based on theory, then measure, then explain any discrepancy. This habit reveals wrong assumptions and builds accurate mental models of RF behavior.
3. Running Labs in Too-Controlled an Environment
Network labs performed in RF-quiet rooms, with devices 1 meter apart, and no competing traffic give unrealistically good results. Add challenges to lab exercises: introduce interference, add distance, add obstacles, add concurrent devices. Lab results should challenge theory, not merely confirm it.
4. Not Documenting Observations During Lab Work
Lab exercises require recording raw measurements (RSSI values, throughput numbers, latency measurements) at the time of observation, not reconstructed afterward. Post-hoc documentation introduces errors and misses transient observations. Keep a real-time measurement log during all lab work.
🏷️ Label the Diagram
💻 Code Challenge
12.11 Summary
This chapter series provides hands-on experience with wireless network analysis and implementation:
Cellular modem bring-up connects the concepts to practice: power, UART, SIM readiness, and network registration using AT commands
Wi-Fi channel scanning turns spectrum congestion into actionable channel plans (1/6/11) for 2.4 GHz deployments
Path loss measurements highlight real-world deviations from theoretical models due to obstacles, multipath, and interference
Link budget sanity checks help you decide quickly whether a deployment is viable (or needs a different band/topology)
Spectrum monitoring enables longer-term logging and reporting to catch time-of-day interference patterns
Coverage planning helps visualize RSSI heatmaps and dead zones to guide placement and upgrades
12.12 Knowledge Check
Quiz: Mobile Wireless Labs
12.13 What’s Next
With practical RF analysis skills established, continue your wireless IoT journey:
