PTCRB, the 12 most common pitfalls
PTCRB · Pillar
Twelve recurring errors in PTCRB certification that surface during PVG review or operator homologation. Three families: cellular scoping errors, module integration errors, post-certification management errors.
Family 1: Scoping errors
Section titled “Family 1: Scoping errors”1: Choosing an end-of-life cellular technology
Section titled “1: Choosing an end-of-life cellular technology”2G and 3G are in progressive sunset in the US and Canada. Designing a long-duration IoT product (10+ years) on GSM or UMTS exposes to premature obsolescence risk.
How to avoid it: for new IoT products, target LTE Cat-M or NB-IoT whose network roadmaps extend at least to 2035.
2: Forgetting FCC in parallel
Section titled “2: Forgetting FCC in parallel”PTCRB and FCC are complementary but distinct. Many teams think PTCRB suffices for the US market, this is not the case. Without FCC certification, equipment violates 47 CFR rules.
How to avoid it: plan FCC and PTCRB in parallel from start. Many tests are shareable.
3: Underestimating operator homologations
Section titled “3: Underestimating operator homologations”PTCRB is just the first step. Each operator typically adds its own requirements (Verizon OPC, AT&T NDD, T-Mobile 5G SA, etc.) with their own timing and costs.
How to avoid it: identify target operators at scoping. Prioritise those whose market volume justifies additional homologation fees.
4: Ignoring North American-specific bands
Section titled “4: Ignoring North American-specific bands”Some bands (B12/B17 at AT&T, B13 at Verizon, B71 at T-Mobile, n66 multi-operator) are specific to USA/CA. A module designed for Europe without support for these bands will not function correctly on North American networks.
How to avoid it: verify critical band coverage for each target operator. Commercial modules (Quectel BG770A, u-blox SARA, etc.) typically cover US/CA + EU bands in a single product.
Family 2: Module integration errors
Section titled “Family 2: Module integration errors”5: Undersized antenna
Section titled “5: Undersized antenna”Substituting the original external antenna with a more compact PCB antenna is tempting to reduce cost, but typically degrades TRP and TIS by 3-6 dB, often enough to fail OTA tests.
How to avoid it: strictly respect the list of compatible antennas documented in the module's Integration Guide. Test with the candidate antenna before sending to external lab.
6: Insufficient ground plane
Section titled “6: Insufficient ground plane”Cellular modules have strict ground plane requirements (minimum size, continuity, low inductance). An undersized PCB degrades RF performance, particularly in low bands (700 MHz, 850 MHz).
How to avoid it: respect the minimum ground plane specified in the Integration Guide. For low bands, plan a PCB dimension ≥ 60 mm in the main direction.
7: Noisy power supply
Section titled “7: Noisy power supply”A supply with insufficient ripple filtering degrades EVM (Error Vector Magnitude) in transmission and SNR in reception. Particularly critical for cellular modems with large TX current peaks (up to 2 A in LTE).
How to avoid it: follow filtering recommendations of the Integration Guide (typically 100 µF + 10 µF + 100 nF + ferrite). Verify residual ripple by oscilloscope before external tests.
8: Inadequate thermal management
Section titled “8: Inadequate thermal management”Cellular modules in sustained transmission (e.g. video download) dissipate 2-5 W. Without adapted thermal management, the module enters throttling and RF performance degrades.
How to avoid it: plan adapted thermal dissipation (thermal pad, metal plane dispersion). Test in hot thermal conditions before OTA tests.
Family 3: Post-certification errors
Section titled “Family 3: Post-certification errors”9: IMEI duplicates in production
Section titled “9: IMEI duplicates in production”Faulty IMEI range management can cause duplicates or out-of-range IMEIs. Operators detect these anomalies during network registration and block concerned units.
How to avoid it: maintain an internal database of issued IMEIs. Verify uniqueness before programming. Calculate Luhn Check Digit automatically.
10: Firmware modified without recertification
Section titled “10: Firmware modified without recertification”A firmware update modifying radio parameters (power, modulation, activated band) typically triggers a simplified PVG submission. Many teams deploy modified firmware without this step.
How to avoid it: lock radio parameters in firmware by signature. Quality workflow forbidding RF modifications without PVG submission.
11: Not following test plan evolutions
Section titled “11: Not following test plan evolutions”PTCRB test plans evolve twice a year. An old certification (3+ years) may no longer comply with current test plans, operators may require recertification.
How to avoid it: follow PTCRB release notes and budget partial recertifications (delta tests) in product maintenance plan.
12: No operator incident management procedure
Section titled “12: No operator incident management procedure”Once in production, incidents may emerge on operator networks (call drops, degraded performance in specific zones, handover problems). Without a formalised procedure, response is slow and conflictual with the operator.
How to avoid it: document an operator incident management procedure from production start. Identify technical contacts at each operator. Mechanism for log forwarding and incident reproduction.
In summary
Section titled “In summary”The 12 PTCRB pitfalls break down into three families:
- Cellular scoping (1-4), end-of-life technology, FCC forgotten, operators underestimated, specific bands ignored.
- Module integration (5-8), undersized antenna, insufficient ground plane, noisy supply, inadequate thermal management.
- Post-certification (9-12): IMEI duplicates, firmware not recertified, test plans not followed, operator incident management absent.
Three useful PTCRB maturity indicators:
- Rate of portfolio cellular products with up-to-date test plans (target: 100%)
- Delay between firmware modification and PVG submission (target: ≤ 8 weeks)
- Operator incident resolution time (target: ≤ 30 days)
For practical implementation, see PTCRB procedure and Tests.
Sources & references
- PTCRB Test Plan changes log , PTCRB www.ptcrb.com/