Here's a sentence you'll rarely hear from a quality person: "The module isn't the problem." But after four years of reviewing connectivity hardware at Quectel Wireless Solutions Co., Ltd., that's the sentence I repeat the most.
I'm in the quality group. I review roughly 200+ unique items a year—modules, Quectel antennas, GNSS boards, modems, and the occasional full wireless solution. I've rejected deliveries. I've argued with suppliers. I've written checklists that made engineers roll their eyes. And through all of it, one pattern keeps showing up:
Most "module failures" aren't module failures. They're integration failures that nobody checked before shipping.
That's a strong claim. I'll prove it with a story.
What I learned the hard way
During my first year in this job, a senior RF engineer told me to always verify antenna matching on the actual production board—not just the reference design. I nodded politely. The reference design had all the right charts, the matching network was textbook-perfect, and we were already behind schedule. So I did what impatient people do: I skipped the verification.
The customer was building a vehicle tracker. The antenna layout on their board was different from our reference, and the ground plane was a bit smaller. A few weeks later, their units started losing GPS signal in urban areas. In OTA test, the module's antenna return loss measured -6.8 dB instead of the reference's -10 dB. Everyone called it "within tolerance." But the real-world result was a tracker that needed a clear view of the sky to keep a fix. That cost the customer weeks of design time and essentially all of their test budget.
Everyone told me to always check. I only believed it after the check skipped me. That's how you learn about quality.
What I actually check
So what does a quality review actually look like when I'm not fighting a deadline?
- Radiated performance, not just conducted. Bench tests with a cable tell you that a module is alive. They don't tell you how it'll behave inside your enclosure, next to a battery, with a human hand hovering nearby. I've seen Quectel antennas that looked ordinary on a datasheet but beat "premium" antennas by 6 dB in the customer's actual chassis—just because the ground plane was a good match. And I've seen the opposite happen to a design that skipped the OTA check to save a week. Test on your hardware, with your plastics. The datasheet will wait.
- Edge cases, not the happy path. What happens at -20°C? What if the firmware sends a wake-up command and the regulator dips? What if the network is congested at peak hours? I once caught a field-failure pattern where a module would lose registration if the SIM card was inserted after power-up. It passed every functional test. It failed in the real world. Those are the issues that generate the strangest support tickets.
- The supplier's process, not just the part. A few years ago, we received a batch of modules where the connector solder joints were slightly off—rounded fillets, a bit of dewetting on the pin. The supplier said it was "within industry standard." I said no. The ground resistance was 2.2 Ω when our spec says 0.8 Ω. That's the kind of red flag you can't afford to ignore. They redid the batch at their cost, and now every contract includes that measurement.
- Firmware defaults. The electrical side can be fine while the module's default settings are wrong for your use case. I've seen modules ship with power-saving mode set to maximum. Great if you're a battery-powered sensor. Terrible if your product needs to respond in under a second. Read the application note like it's a contract, not a suggestion.
If you've ever heard someone say "we bought a quality module and it still failed," this is usually the missing piece. The module was fine. The integration wasn't.
Why small customers get my full attention
Here's where I'll get personal.
I see a lot of small customers. Startups, independent engineers, teams doing their first cellular product. They don't have a QA department. They don't have an OTA chamber. They buy modules the way everyone buys components—on price and specs.
Last year, a startup came to us with a connected blood pressure monitor. The design was thoughtful: good sensor, clean UI, and the blood pressure monitor symbols on the display were clearly designed with user trust in mind. The Bluetooth wave, the cloud upload arrow, the battery icon—they cared about how a patient would read that device at 6 AM.
They chose another module because it was $1.80 cheaper per unit. On a 3,000-unit first batch, that's $5,400 in savings. I understand. Startups have to save wherever they can.
Three months later, they came back. The module was putting itself into a deep sleep and not waking up fast enough. The monitor would show the cloud icon even when the session had dropped. Users would take a reading, see the cloud icon, assume it synced, and the data was gone. The blood pressure monitor symbols were, in effect, lying to the user.
The $5,400 savings turned into something closer to $40,000 in engineering time, re-qualification, and replacement units. The startup almost dropped the product line. They're still a customer, and I'm glad. But it was a near miss.
Phones work the same way. Consumers never hear the word "module." They just know the phone's signal is bad, or the battery drains fast, or the data connection keeps dropping. The module inside is the invisible reputation of the device. A phone OEM who chooses by price alone is betting the whole brand on a few dollars' worth of savings.
When I say I care about small customers, it's not a slogan. It's because the stakes are existential for them. A big OEM can absorb a bad batch. A startup can't.
The tool debate misses the point
I have a theory about why these integration mistakes keep happening. People spend more time debating equipment than defining process. It's the same reason you see forum threads about "Klein vs multimeter"—as if the tool itself produces quality.
Here's a truth from someone who signs off on products: an engineer with a $40 multimeter and a clear test plan will catch more issues than an engineer with a $400 meter and no plan. The tool doesn't make quality. The process does. The same applies to connectivity. You can buy the best module in the world and still fail the launch if you don't test it inside your product, with your software, in your real-world conditions.
But certification isn't a guarantee
At this point, someone always asks: "If the module is certified, doesn't that mean it's reliable?"
Certification means the module meets its own specification. It doesn't mean it will work in your device, next to your antenna, powered by your power management IC, running your firmware. That gap is bigger than people think.
I don't have hard data on how many IoT projects die for this reason—not industry-wide. But based on the returns we see, the support tickets, and the design reviews I attend, my honest sense is that integration mistakes outweigh actual module defects by a wide margin. I wish I could give you a precise number. I can't. But I've watched the pattern repeat enough to know it's real.
Bottom line
If you're developing a connected product, change your mindset. The module is the start, not the finish. Budget real time for integration testing. Pay attention to antenna placement, power states, and firmware defaults. Choose a supplier who treats your 50-unit order as seriously as a 50,000-unit order—because the ones who do are the ones who'll be there when something weird happens at 2 AM. And from experience, that's exactly when weird things happen.
This was accurate as of early 2025. The connectivity market moves fast, so verify current modules, certifications, and availability before you lock in your design.
