Bluetooth BQB Certification – 9 Common Failure Reasons and How to Avoid Them

2026-08-17

To bring a Bluetooth product to market, you must pass SIG qualification – the industry calls it BQB certification. Many manufacturers pass internal testing – but fail formal certification. Certification is not just RF testing – protocol stack, Profile compatibility, RF performance, and documentation completeness – any weak link fails.


一、BQB Certification – Nine Most Common Traps

1. RF testing fails

RF testing is a hard threshold – all Bluetooth products – regardless of version or Profiles – must pass.

·Excessive transmit power: common – some push power for range – exceeding class limits = fail.

·Spurious emissions: often due to PCB layout and shielding – some issues can be mitigated by RF register tweaks or modulation optimisation – severe cases require hardware changes.

·Frequency offset: depends on crystal accuracy – TCXO with ±10ppm is a practical guideline – SIG does not mandate a hard accuracy threshold.

Prevention: tune RF at the design stage – use a vector analyser for antenna matching – keep VSWR ≤2:1. Run pre‑testing before formal submission.

2. Protocol‑stack configuration defects

Protocol stack failures are a major trap. The product may function – but certification checks protocol implementation against the Core Specification. Common issues: incomplete feature implementation, incorrect optional‑function configuration, and non‑compliant security settings.

GATT is the foundation of BLE communication – with low pass rates. Typical failures: missing service‑discovery information, incorrect characteristic notification behaviour, and wrong attribute permissions – root cause: GATT table deviation from the Core Specification.

Prevention: use Ellisys or Frontline packet analysers – check against the Core Specification line by line. Choose SIG‑qualified stacks – self‑developed is risky. Even commercial SoC stacks may not all be qualified – check the DN list when purchasing modules.

3. Profile compatibility issues

Declared Profiles must follow SIG behaviour specifications:

·A2DP: audio link and codec negotiation.

·HFP: call establishment and voice‑channel switching.

·AVRCP: remote control.

Some failures only appear under specific device states – requiring repeated firmware refinement.

Prevention: internal testing against a single reference device is not enough – test against multiple mainstream models. Testing against only one = interoperability failure.

4. Incomplete certification documentation

Documentation rejection – usually because functions are claimed but not tested – or test evidence is incomplete. Reviewers take all Bluetooth functions and Profiles from the spec sheet – and cross‑check against test plans and reports.

PICS declaration errors are frequent: mark only actual functions – don't over‑mark or miss them. PCB diagrams and schematics missing RF trace and component parameter markings are also returned.

5. Incorrect module referencing

For whole‑product EPL listing using a certified commercial module – module DN referencing is tricky:

·End‑product type DNs cannot be reused.

·Use Component type DNs – Subsystem type DNs also support whole‑product referencing.

Not all Component DNs qualify – check the module's certification scope and antenna‑control terms.

Peripheral circuit changes without filing: antenna or matching‑circuit changes require RF retesting – power‑supply changes require EMC retesting. Confirm DN type with the supplier at selection – avoid submission rejection.

6. Test samples differ from mass‑production

SIG requires samples to have identical software/hardware versions to mass production – special firmware or development boards are rejected. Changing firmware during the certification process is a major risk – each change may require re‑verification. Freeze versions before testing – no hardware/firmware changes during certification.

7. Duplicate model number in SIG database

Model numbers cannot be duplicated under the same applicant – duplicates from other companies do not cause rejection. Before submission, check the SIG database – if the model is taken – change it and submit – avoiding rework.

8. Antenna information inconsistency

For EPL listing reusing a module's DN – antenna gain, type (internal/external), and manufacturer must match the module DN constraints – mismatches with the report cause rejection. For self‑developed whole products, antenna changes to the same specification are allowed – update filing – not necessarily full RF retesting. Before submission, confirm antenna parameters in the report match the physical sample – model changes require a new report.

9. Claimed functions don't match testing

If the spec sheet claims LE Audio but the test plan doesn't include the cases – review rejects. Two traps:

·Chip support ≠ you can claim it – if you claim it, you must test it.

·Even if the spec sheet doesn't mention it – if firmware actually enables the feature – QPDR review still requires testing.

Prevention: confirm LC3 and Auracast support at chip selection – if not supported, don't include them in the spec sheet.


  二、How to Reduce Failure Risk

Pre‑testing is worth it – one week of pre‑testing catches most risks. During certification, leave budget for remediation – first‑pass is not guaranteed. When choosing a lab, select one that offers pre‑testing and documentation guidance – more stable than those offering only formal testing.

Before submission, confirm firmware version, RF parameters, and application documents all match. If the lab discovers version mismatches mid‑test – the process restarts.


  三、Submission Timing Recommendations

Prepare two sets of samples – one for testing, one for backup. If RF issues arise – the backup allows immediate modification and retesting. Maintain communication with the lab during testing – earlier issue detection is easier to fix.

Timeline: plan for 2–3 months. From sample submission, testing, document review, to EPL listing – any step can cause delays.

Bluetooth specification updates do not force re‑certification. Only hardware/RF changes, firmware protocol changes, or claimed Profile changes require change filing. Core Spec iteration alone – no immediate re‑certification.


For BQB certification, contact BlueAsia at 13534225140 (King) or email king.guo@cblueasia.com.