蓝牙医疗设备芯片选型指南：连续血糖监测（CGM）与动态心电贴的低功耗 BLE SoC 对比与合规成本分析

Why the Profile Stack, Not the Datasheet, Decides Your CGM or ECG Patch BOM

When a hardware team sits down to pick a Bluetooth Low Energy SoC for a continuous glucose monitor (CGM) or a dynamic ECG patch, the first instinct is to compare datasheets: RX sensitivity, TX current at 0 dBm, sleep current, flash size, price per reel. That comparison is necessary but insufficient. For medical wearables, the two decisions that actually determine whether a product ships on time and stays profitable are (1) whether the SoC vendor's Bluetooth stack supports the profile your regulatory pathway expects, and (2) how much of the compliance burden — profile qualification, interoperability testing, RF test modes — the vendor absorbs versus how much lands on your team.

This guide focuses on those two levers. It uses the Bluetooth SIG's own adopted specifications — the Health Device Profile (HDP v11, adopted 2012-07-24), the Heart Rate Profile (HRP v10r00, adopted 2011-07-12), and the Health Thermometer Profile (HTP v10r00, adopted 2011-05-24) — as the reference framework, because these documents define the interoperability contracts that regulators and phone platforms still implicitly rely on. It then maps those contracts onto real CGM and ECG-patch architectures, compares representative SoC families on measurable criteria, and gives a procurement checklist with cost ranges you can take into a design review.

1. The Profile Landscape: What the SIG Actually Adopted, and What It Means for a Patch

The three SIG documents in scope were all prepared by the Medical Devices Working Group (the HDP document lists 该 Email 地址已受到反垃圾邮件插件保护。要显示它需要在浏览器中启用 JavaScript。; HRP and HTP list 该 Email 地址已受到反垃圾邮件插件保护。要显示它需要在浏览器中启用 JavaScript。). Their revision histories are instructive for anyone planning a long-life medical product:

• HDP v11 — first adopted as v10r00 on 2008-06-26, revised through D11r00 (2012-01-23) for errata ESR05 (E2947, E2888, E2937), and re-adopted as V11 on 2012-07-24. HDP works together with the Multi-Channel Adaptation Protocol (MCAP), per the abstract, to enable healthcare and fitness usage models. This is the heavyweight option: it defines a reliable, multi-channel data transport over L2CAP with a formal "Source/Sink" model.
• HRP v10r00 — adopted 2011-07-12, built on the Heart Rate Service and explicitly scoped to "fitness applications," enabling a Collector to connect to a Heart Rate Sensor. Its revision history (D09r00 through D09r03, incorporating BARB and MED WG review feedback) shows a profile that converged quickly.
• HTP v10r00 — adopted 2011-05-24, enabling a Collector to interact with a Thermometer sensor "for use in healthcare applications," with an interoperability-test (IOP) build at D09r05 in December 2010 before Board adoption.

The practical takeaway for a CGM or ECG patch is a split decision, not a single answer:

• HDP/MCAP is the right transport when you need guaranteed, ordered, multi-stream delivery — for example, a patch that simultaneously streams raw ECG, derived heart rate, and a device-status channel, with acknowledged delivery. HDP's Source/Sink abstraction and MCAP reliability were designed exactly for this. The cost is stack complexity, larger flash/RAM footprint, and fewer off-the-shelf phone-side implementations.
• GATT-based profiles (HRP for heart rate, a glucose service for CGM) are the right choice when phone interoperability and app-store ecosystem matter more than transport guarantees. HRP is explicitly a fitness profile, and that framing matters: it is well supported by mobile OS stacks and is the path of least resistance for an ECG patch that reports derived heart rate to a consumer or clinician-facing app.
• HTP is directly relevant to CGM in one specific way: it is the SIG's template for a healthcare sensor with a Collector, including the measurement-interval and temperature-type semantics that a glucose sensor's calibration and drift-compensation logic mirrors. Use it as a design reference for your GATT service structure even if you do not qualify against it.

A critical, verifiable point: these documents are profiles, not radios. None of them specifies an SoC, a crystal, or a current profile. That means your SoC selection is driven by which profile stack the vendor ships and qualifies, not by the profile text itself. This is where most BOM comparisons go wrong.

2. Architecture Reality Check: CGM vs. ECG Patch Are Different Radio Problems

Before comparing chips, separate the two products, because their BLE duty cycles and data contracts differ sharply.

2.1 CGM: low duty cycle, long life, tiny payloads

A CGM sensor (subcutaneous filament, 10–14 day wear) reports a glucose value every 1–5 minutes. Each report is a handful of bytes plus status flags (trend arrow, calibration state, sensor age). The radio problem is dominated by sleep current and connection-interval efficiency, not throughput. A representative architecture:

• SoC in System ON sleep between advertisements/connections; wake on RTC.
• Advertising interval of 1–5 s when unpaired; connection interval of 1–10 s when paired, with slave latency to skip empty connection events.
• Average radio current budget: a few microamps to low tens of microamps, dominated by the sleep oscillator and the periodic wake, not the TX burst.

The GATT service should follow the HTP pattern: a measurement characteristic with a timestamp and a status field, plus a separate "intermediate" characteristic for calibration events. Do not invent a proprietary framing if you intend to interoperate with clinical gateways; the SIG's Collector/Sensor model is the lingua franca.

2.2 ECG patch: bursty, higher throughput, event-driven

A dynamic ECG patch (24–72 h Holter-style, or 7–14 day event monitor) samples at 125–500 Hz per lead. Raw streaming at 250 Hz × 2 bytes × 2 leads is roughly 1 kB/s — trivial for BLE's ~1 Mbps PHY, but the duty cycle is bursty: the patch may buffer minutes of data and upload in a burst when the phone is present, or stream continuously during a symptomatic event. The radio problem is dominated by peak throughput, connection stability at range (body-worn, under clothing), and coexistence with the phone's Wi-Fi.

This is where HDP/MCAP earns its complexity: if you need to stream raw ECG while simultaneously reporting derived HR and device status with acknowledged delivery, MCAP's multi-channel model is the SIG-blessed way to do it. If you only need derived HR to an app, HRP is sufficient and far cheaper to integrate.

2.3 The water-resistance and antenna constraint nobody budgets for

Both products are body-worn and often shower-rated (IPX7/IP68). A patch with a potted or overmolded antenna loses 3–6 dB of link budget versus a free-space design. This directly affects SoC choice: you need either a higher-sensitivity receiver or a higher TX power option, and you need a vendor whose reference design includes a body-worn antenna model. Budget for a 2-layer flex or a ceramic chip antenna with a measured body-loss characterization, and validate at the worst-case orientation (patch on the torso, phone in a pocket on the opposite side).

3. SoC Comparison: What to Actually Compare

Rather than quote datasheet numbers that vary by revision, compare SoC families on the criteria that determine medical-product outcomes. The table below is a decision framework, not a spec sheet; fill in the exact figures from the current datasheet for your shortlist.

• Stack/profile support: Does the vendor ship a qualified GATT stack with glucose and heart-rate services, and optionally HDP/MCAP? Is the profile qualification certificate transferable to your product, or must you re-qualify?
• Sleep current and wake latency: For CGM, the sleep current at 1.8–3.6 V with RTC running is the single largest contributor to average current. Wake latency determines how long the radio stays on per event.
• Peak TX current and PA efficiency: For ECG bursts, the PA's efficiency at the required output power (often +4 to +8 dBm to survive body loss) determines battery sag and thus the minimum usable battery voltage.
• Flash/RAM headroom: HDP/MCAP plus a secure bootloader plus OTA plus application logic can exceed 256 kB flash and 32 kB RAM. A GATT-only HRP/glucose build fits comfortably in 128–192 kB.
• Security and OTA: Medical devices need secure boot, signed OTA, and often a secure element or TrustZone-class isolation. Check whether OTA is dual-bank (safe rollback) and whether the vendor's stack supports LE Secure Connections and bonding persistence.
• Regulatory artifacts: Does the vendor provide a Bluetooth SIG Declaration ID / qualification listing you can reference, plus RF test-mode firmware and a modular-approval-friendly reference design?

Representative families to shortlist (verify current figures against each vendor's latest datasheet and qualification listing):

• Nordic nRF52/nRF53 series — strong GATT stack ecosystem (SoftDevice / nRF Connect SDK), good sleep current, well-documented body-worn reference designs; HDP/MCAP is not a first-class offering, so plan on GATT-based services.
• Silicon Labs EFR32BG series — solid RF performance and a mature stack; useful when you need higher TX power for body-loss margin.
• TI CC26xx/CC27xx series — good low-power credentials and a long medical track record; check stack/profile support for your specific service.
• Dialog/Renesas DA14xxx — very low sleep current, attractive for CGM; verify flash headroom for your OTA and security requirements.
• Ambiq Apollo series — sub-threshold MCU architecture with integrated BLE; compelling for the CGM average-current budget, but confirm the BLE stack's profile coverage.

Do not treat this list as a ranking. The correct method is to build a weighted scorecard: for CGM, weight sleep current and stack simplicity highest; for ECG, weight peak TX efficiency, flash headroom, and HDP/MCAP (or multi-service GATT) support highest.

4. Real-World Usage Scenarios That Change the Selection

Scenario A: 14-day CGM, phone-tethered, 5-minute reporting

Average current is the whole game. A 220 mAh coin cell must last 14 days at, say, 60 µA average — that is a hard budget. Here, the SoC's sleep current and the connection-interval/slave-latency tuning matter more than TX power. Choose the part with the lowest RTC-inclusive sleep current and a stack that lets you set a 10 s connection interval with slave latency of 4–9 without breaking the phone's supervision timeout. Validate against both iOS and Android, because their connection-parameter acceptance policies differ.

Scenario B: 48-hour ECG patch, burst upload every 30 minutes

Peak current and flash headroom dominate. The patch buffers 30 minutes of 250 Hz × 2-lead data (roughly 1.8 MB at 2 bytes/sample — too much for on-chip flash, so you need external flash or on-the-fly compression). The BLE link must sustain a burst at the negotiated MTU and connection interval without dropping. Here, HDP/MCAP's reliable multi-channel transport is genuinely useful, and you should verify the vendor stack's throughput at your target connection interval with a real phone, not a sniffer.

Scenario C: Clinic gateway with HDP Collector

If your customer is a hospital gateway rather than a phone, HDP is the interoperability contract. Confirm that your SoC vendor's stack implements the Source role and that you can produce the SIG qualification evidence. This is the scenario where choosing a GATT-only stack "because it's simpler" becomes a multi-quarter integration problem.

5. Compliance Cost Analysis: Where the Money Actually Goes

Compliance is not a line item; it is a schedule risk. Break it into four buckets and budget each explicitly.

• Bluetooth SIG qualification: If you build on a vendor's already-qualified component (a "qualified design" you reference), your own qualification is a Declaration plus a modest fee. If you implement a profile the vendor does not cover, you pay for additional testing and possibly a new Declaration ID. Budget engineering time for the qualification test plan and the listing paperwork.
• Profile/interoperability testing: GATT-based HRP/glucose testing is largely covered by the vendor's stack test suite plus your own phone matrix. HDP/MCAP testing is heavier: multi-channel setup, reliability, and Collector-side interoperability. Expect meaningfully more test-engineering hours for HDP.
• RF/regulatory (FCC/CE/ISED): A pre-certified module with modular approval dramatically reduces cost and time versus a chip-down design. Chip-down buys BOM savings but adds radiated-emissions and RF-exposure testing, plus antenna retuning. For low-volume medical patches, module-based designs usually win on total cost; for high-volume CGM, chip-down can pay back.
• Medical device regulatory (FDA 510(k) / EU MDR): The radio choice affects the cybersecurity and interoperability sections of your submission. A stack with documented security features (LE Secure Connections, signed OTA, secure boot) reduces the evidence burden. Budget for a cybersecurity review regardless of SoC.

A practical cost heuristic: the delta between a GATT-only design and an HDP/MCAP design is dominated by engineering and test hours, not by per-unit silicon. If your volume is under roughly 100k units/year, the HDP path's added NRE usually exceeds any per-unit savings from a cheaper SoC. If you are a clinic-gateway vendor with a fixed interoperability requirement, the HDP path is non-negotiable and should be budgeted as a platform cost amortized across products.

6. Actionable Buying and Using Guide

Step 1 — Fix the interoperability contract first. Decide whether your product must speak HDP/MCAP (clinic gateway, multi-stream reliable transport) or GATT profiles (phone app, HRP for derived HR, a glucose service for CGM). Write this down before you open a single datasheet. The SIG documents are the reference: HDP v11 for the multi-channel healthcare model, HRP v10r00 for heart-rate collector/sensor, HTP v10r00 as the template for a healthcare sensor with measurement intervals and status.

Step 2 — Build a weighted scorecard. For CGM, weight sleep current (40%), stack simplicity and profile coverage (30%), flash/RAM headroom for OTA and security (20%), and cost (10%). For ECG, weight peak TX efficiency and body-loss margin (30%), flash headroom and HDP/MCAP or multi-service GATT support (30%), stack maturity (25%), and cost (15%). Score three shortlisted families against the current datasheets and qualification listings.

Step 3 — Demand vendor artifacts, not promises. Ask each vendor for: the SIG qualification listing and Declaration ID; RF test-mode firmware; a body-worn antenna reference design with measured loss; dual-bank OTA with rollback; and a written statement of which profiles their stack implements. If a vendor cannot produce the qualification listing, treat the profile support as unverified.

Step 4 — Prototype the worst case, not the best case. Build a body-worn mock with the patch in its final enclosure and the phone in a pocket on the opposite side. Measure connection stability at the target connection interval, and measure average current over 24 hours with the real reporting cadence. Datasheet current numbers assume ideal conditions; your number will be higher.

Step 5 — Decide module versus chip-down on total cost. For low-to-mid volume medical patches, a pre-certified module with modular approval usually wins after you account for RF testing, antenna retuning, and schedule risk. For high-volume CGM, chip-down with a vendor reference design can pay back, but only if you have in-house RF test capability.

Step 6 — Budget compliance as schedule, not just money. Put the SIG qualification, profile interoperability testing, RF/regulatory testing, and cybersecurity review on the critical path with owners and dates. The most common failure mode is discovering in the last quarter that the chosen stack does not implement the profile your gateway requires — a problem that no amount of silicon optimization can fix.

7. Bottom Line

For a phone-tethered CGM, optimize for sleep current and GATT simplicity, follow the HTP measurement/status pattern, and choose a vendor with a qualified GATT stack and a body-worn reference design. For a clinic-gateway ECG patch, accept the HDP/MCAP complexity because it is the SIG's reliable multi-channel healthcare contract, and budget the added test-engineering hours accordingly. For a consumer ECG patch that only reports derived heart rate, HRP is the pragmatic, well-supported choice. In every case, the SoC decision should follow the profile decision, and the profile decision should be backed by a vendor qualification listing you can actually cite in your regulatory submission.

💬 欢迎到论坛参与讨论： 点击这里分享您的见解或提问