☎ +86-551-6586-9386 [email protected] Buyer's Guide EN | DE | JP
Blog

Why Your IoT Device Gets Worse Signal Than Your Phone (The Spec Sheet Won't Tell You)

Posted on Wednesday 16th of September 2026 by Rowan Whitaker

The bench test that lies to you

At least twice a month I get a message that reads roughly like this: "The unit works fine on my desk. In the field it drops the connection twice a day."

Usually it's a connected health product — a blood pressure monitor with cellular backhaul, or a remote patient monitor. And usually the person writing me has already done the obvious thing: they put their phone next to the device, the phone had four bars, and the device had none. So the module must be bad, right?

I've been on the receiving end of that conclusion enough times to say it plainly: the module is almost never the problem. And if you walk into a vendor conversation convinced that it is, you'll spend three months and a real chunk of budget solving the wrong thing.

What's actually going on is more boring, and considerably more fixable.

What a module datasheet is actually measuring

Here's the part that took me an embarrassingly long time to internalize. When a vendor publishes a sensitivity number like -108 dBm or a max output of 23 dBm, they measured that on a reference board — a clean PCB with a matched 50-ohm trace, an ideal antenna, no enclosure, no battery cable, no display flex. (Note to self: I should print that sentence on a card and hand it to every new product manager on day one.)

Your device is not a reference board.

In our Q1 2024 review of two connected-monitor products, we measured receive degradation of 4 to 6 dB between the module pad and the antenna connector. That is not a module defect. That is the cost of the things nobody puts in the block diagram: the U.FL connector, the coax pigtail, the ground plane you had to shrink to fit the enclosure, the plastic housing with a conductive coating you didn't know was conductive.

None of it shows up in the datasheet. A datasheet describes the module. It does not describe your integration of the module — which is where most field failures live.

"Band support" is not "band performance"

A module listing LTE Band 12 or 5G n78 tells you it can operate there. It does not tell you how well your finished product operates there — at the edge of cell coverage, at -10°C, with the antenna detuned by the enclosure it's sitting in.

I've watched this bite teams on both 4G and 5G designs. A Quectel EC25 on an LGA footprint that behaved beautifully in the lab, mounted in an aluminum enclosure with an internal antenna, lost roughly 8 dB of effective radiated power versus the same board on the bench. Same module. Same firmware. Different physical reality.

The 5G side is worse, not better. More bands, more complexity, more ways for the RF path to go subtly wrong. If someone told you an RM520N-GL would simply drop into a design and perform, they were describing the module, not the integration.

The certification belongs to the module, not to your device

This one I got wrong personally.

I assumed that a module carrying GCF, PTCRB and carrier approvals meant our finished product was covered. Didn't verify. Turned out the module's certificates cover the module — the assembled device needed its own approvals, and the carrier's test program evaluates the device as a system, antenna and all.

That assumption cost us a launch window. Not a catastrophic one, but a real one.

It gets thicker if you're building anything medical. A cellular blood pressure monitor is a medical device and a radio. That means the symbol set on the label (per ISO 15223-1), the EMC standard for ME equipment, and the radio approvals all apply — and the module vendor's paperwork covers roughly one of those. Verify current requirements with your notified body or test lab; the rules shift, and they shift quietly.

Why your phone wins — and why that comparison will mislead you

People ask me this constantly, in roughly these words: why are phones so strong? The phone gets signal in the basement. The device doesn't.

The honest answer is that the comparison was never fair, and it was never designed to be.

  • A phone carries multiple antennas, often 4x4 MIMO, with physical spacing your product can't afford.
  • Its ground plane runs roughly 150mm — comparable to the wavelength it's trying to receive. Yours might be 40mm.
  • The modem and RF front end are tuned as one system, with the antenna, the enclosure and the operator's hand all inside the model.
  • The vendor spent years and a lot of money in carrier labs to earn the performance you're watching.

You are not going to match that with a module and a chip antenna. That's not a knock on the module — it's what the physics and the budget say. (If you ask me, the industry would save itself a lot of grief by stating that plainly on page one of every integration guide.)

What this costs when you find out late

The failure mode is almost always the same shape: passes in the lab, ships, then generates returns nobody can reproduce on a bench.

We had a run of 8,000 units where the field failure rate sat around 6% — call it 480 devices. Root cause traced back to connector seating tolerance on the RF pigtail. Not a design flaw. Not a module flaw. A process window that was never defined, because the prototype units were hand-assembled by an engineer who was careful (ugh, always the same story).

The redo cost us roughly $22,000 in labor and re-testing, plus a two-month slip on a follow-on order. The customer saw a late launch. We saw a late launch and a bill.

I have mixed feelings about how much of this is genuinely preventable versus just the cost of doing hardware. On one hand, every one of those 480 failures was avoidable with a defined torque spec and a first-article check. On the other, I've watched teams spend six figures over-engineering an RF path for a product that never left the warehouse. You have to choose where to spend the attention, and that choice is fairly close to the whole job.

What I'd do differently

Nothing exotic. Just the things that would have saved us two bad quarters.

  1. Test the assembled device, not the dev board. In the enclosure, with the final antenna, before design freeze. If you can only afford one test, make it this one.
  2. Budget the RF path as a loss. Assume 3–5 dB between the module and the air, and build the link budget with that hole already in it. Not with datasheet numbers.
  3. Separate the two certification questions. Module approval is one thing. Device approval — FCC, CE, ISED, carrier — is another, and it has its own timeline you must plan against.
  4. Keep a footprint-compatible fallback. A common LGA land pattern that accepts more than one 4G module, or an M.2 socket for 5G, buys you optionality when supply or performance forces a change.
  5. Define the process window. Connector torque, cable bend radius, antenna mounting torque. Write it down. Your contract manufacturer is not psychic.

A vendor who tells you what they don't do

One last thing, and it's the criterion I've come to weight most heavily when I'm evaluating anyone.

A supplier once told me, "Antenna design isn't our strength — here's the firm we'd point you to." That single sentence earned more trust from me than three years of quarterly business reviews did. They weren't the cheapest. They weren't the fastest. They were the ones who told me where the edge of their expertise was, before I found it the expensive way.

That's rare, and it's valuable. A vendor claiming to do module, antenna, certification, enclosure and firmware flawlessly is telling you something about their sales process, not their engineering.

There's something satisfying about finally having this on paper. After two bad quarters and a lot of arguing about whose fault it was, our intake checklist now carries a single line that reads: "Has the assembled unit been tested at the antenna?" One line. It would have saved us $22,000.

Anyway — check the connector. It's usually the connector.

author-avatar
Rowan Whitaker

Rowan Whitaker is a fiber-optic systems analyst covering SFP and QSFP transceivers, OLT, ONT, ONU, passive splitters, optical amplifiers, and CWDM and DWDM platforms. He applies IEC 61280-4-2 and IEC 61300 methods while examining insertion loss, return loss, optical power budget, bit error rate, wavelength drift, dispersion, channel spacing, and transmission reach. His guides help carriers, data-center teams, system integrators, and sourcing specialists compare capacity, interoperability, link margin, serviceability, and migration paths.

Leave a Reply