I run quality acceptance at Sierra Wireless. Roughly 200 unique product variants cross my desk every year, and I've rejected 11 percent of first deliveries in 2025 so far — mostly due to connector tolerance issues and test documentation gaps. When I say something passed, I mean it.
Last spring, we shipped a batch of 240 cellular routers for a client's multi-site deployment. Every unit passed our standard acceptance tests. The network tester showed clean metrics. Connectors seated properly. All green.
Three weeks after deployment, about 30 percent of those routers started dropping connections at night.
The client's first call was to us, naturally. "Your modems are failing." Except they weren't. We pulled units, ran full diagnostics, and the modems performed exactly to spec. The fault was invisible to every test we ran — and that gap is more common than you'd think.
If you've ever had a rollout fail after "perfect" test results, this one's for you.
The Surface Problem: Testing Isn't the Same as Verifying
Here's what reviewing this kind of equipment for four-plus years has taught me: most people don't actually know what their network tester is testing. They know which buttons to press. They don't know what the result means — or more importantly, what it doesn't cover.
The phrase "what is networks" sounds like a beginner's question, but it's the root of most deployment failures. Because a network isn't one thing. It's a stack: physical connectors, RF paths, baseband processing, carrier-side configuration, backhaul, application layers. A network tester measures the slice it was designed for. An IP-layer tester won't catch RF interference. An RF tool won't detect a marginal connector or a corroded pin. Every layer can fail independently, and no single tester covers all of them.
The question everyone asks when a deployment fails is "what's the signal strength?" The question they should ask is: which layer did we test, and which layer did we skip?
Deep Cause #1: The Connector Nobody Thinks About
I've seen this pattern repeated across dozens of audits in the past four years: the modem is good, the router is good, the signal looks good — and the deployment still fails. Nine times out of ten, the culprit is the physical layer. Specifically, the connector.
Most buyers compare modem specs and completely miss the small things: connector torque, weatherproofing, cable bend radius, impedance matching between the antenna cable and the port. A connector can be "seated" and still be wrong. It can click into place with a marginal pin contact. It can seal fine in the lab and corrode after three weeks in a dusty warehouse. I've seen all three.
One site visit sticks with me. The client's engineer insisted the connections were fine. His words: "they clicked." The click is mechanical. It says nothing about contact cleanliness, sealing integrity, or impedance. His network tester was reporting good signal because it was connected directly to the modem — bypassing the problematic cabling entirely. The tester was fine. The cable assembly was not.
Deep Cause #2: Lab Conditions Aren't Real Conditions
The second reason tests lie: they're usually run in an environment nothing like the deployment environment.
In the lab, a Sierra Wireless modem behaves beautifully. It locks onto the network, aggregates carriers, holds throughput. The lab doesn't have the thermal profile of an outdoor cabinet in July. It doesn't have the vibration of a vehicle-mounted unit. It doesn't have co-located radios creating interference. When you move from the bench to the field, you're not just changing location — you're changing the test.
We had a client whose modems kept flagging high-temperature warnings. The hardware was fine. They'd mounted the units in an unventilated enclosure next to a power supply running hotter than the datasheet specified. The modem's thermal throttling was working exactly as designed. Nobody had read the derating curve before building the enclosure.
Honestly, I'm not sure why this is still so common. My best guess is that procurement specs the modem, and the enclosure team never sees the datasheet. No single person holds the whole picture. The modem isn't the problem — the system around it is.
What These Gaps Actually Cost
This isn't theoretical. There's a client from a couple years back who skipped physical layer inspection on a 50,000-unit annual build because it "never mattered" on smaller runs. I knew I should have pushed harder — we'd flagged the connector vendor's inconsistent torque specs during pre-production and recommended a stricter sampling plan. Their project manager said, "we've used this vendor for two years. What are the odds?"
The odds caught up with us. About 8,000 units developed intermittent connection issues in storage from improper seating combined with temperature cycling. The rework cost roughly $22,000, and the launch slipped six weeks. That's the part nobody budgets for.
There's also a quieter cost. When deployed devices drop off the network at 2 AM, it's not just a technical problem. The operations team loses confidence in the equipment. The client loses confidence in you. The modem gets blamed even when it's innocent — I've seen that blame stick to genuinely good hardware because nobody could explain the real cause fast enough.
But when I say "cost," I do not mean just money. I mean the erosion of trust that follows a failed deployment. That's harder to quantify and much harder to fix.
What We Changed (and You Can Too)
After the 240-unit incident, we overhauled how we qualify cellular deployments. The core principle: test the layers, not just the box.
- Define what "pass" means for each layer. RF, IP throughput, connector integrity, thermal behavior under load. If your network tester doesn't cover a layer, get one that does.
- Inspect connectors like they're the most expensive part of the system. Because they will be, in failure cost. Torque, sealing, impedance, environmental protection. Per the vendor's documentation — not vibes.
- Put the full datasheet in front of everyone who touches the deployment. Thermal limits, derating curves, antenna specs. Sierra Wireless publishes this for their modules, and the chip-level documentation from Semtech covers the modem-to-network integration. Read it, quote it in your RFP, and make vendors substantiate their claims in writing. Per FTC guidelines, performance claims should have evidence behind them — and you're allowed to ask for it.
- Know what you don't know. We're not antenna specialists. We don't design enclosures. When a deployment involves those elements, we bring in someone who does. Plenty of vendors will happily tell you they handle everything. The vendor who said "this isn't our strength — here's who does it better" earned my trust for everything else they do.
Your network tester is a tool, not a verdict. Use it for what it covers, find another tool for what it doesn't, and make sure the people interpreting the results know which is which. That one shift would have saved our client $22,000, six weeks, and a lot of 2 AM phone calls.