Bluetoothの消費電力を測定・分析する¶

この記事では、Bluetooth Low Energy（BLE）、Classic Bluetooth（BR/EDR）、およびデュアルモード製品で両方を組み合わせて動作させる場合の、デバイスの実消費電力を測定する方法を説明します。各シナリオで測定対象の範囲を定め、電流と電圧を記録し、トレースの主要な区間を説明できるだけのファームウェア情報を取得します。

この記事のClassic Bluetoothおよびデュアルモードの部分は、BR/EDRをサポートするデバイスとファームウェア構成にのみ適用してください。BLE専用製品でも同じ方法を使い、測定シナリオはBLEのみを対象としてください。

NordicのOnline Power Profiler for Bluetooth LEは、BLEの消費電力を考える際の参考になります。Nordicによると、これは実測値を基に期待値を推定するモデルであり、特定のデバイスを直接測定するものではありません。公開されている精度情報はNordicのリファレンス機器に限られ、SF32には適用できません。また、Classic Bluetoothやデュアルモード製品も対象外です。モデルは測定項目を決める参考にとどめ、製品の消費電力は対象デバイスを実測して確認してください。

何を測定しているかを定義する¶

「Bluetoothの消費電力」が指す範囲はさまざまです。無線部だけを測定すれば接続パラメーターの最適化には役立ちますが、コントローラー、アプリケーションCPU、センサー、ディスプレイ、メモリー、電源を含む製品全体の消費電力は分かりません。

製品の電池寿命を評価する場合は、可能な限り電池入力または製品の主電源入力で測定してください。電流と同時に電圧も記録すれば、電源条件を無視した電流値だけでなく、電力やエネルギーとして結果を評価できます。

再現可能なテストを構築する¶

計測器とデバイスの間で測定境界を明確に定め、記録してください。NordicのPower Profiler Kit II（PPK II）は、電圧と電流のレンジが測定条件に合えば、電源供給と電流測定を兼ねる測定器として利用できます。同等のソースメジャーユニットや電流アナライザーも使用できます。重要なのは機器のブランドではなく、測定手順の厳密さです。

PPK IIのSource Meterモードでは測定器がデバイスに給電し、Ampere Meterモードでは外部電源から測定器を経由して給電します。製品の給電経路に合うモードを選んでください。設定した電源電圧は、記録したデバイス電圧の波形ではありません。電圧降下や電池電圧の変化がエネルギーに影響する場合は特に、測定点の電圧も監視してください。

DUTを接続する前に、PPK IIの動作上限を確認してください。Source Meterモードの出力は0.8～5.0 Vに設定でき、DUT電流の上限は600 mAです。Ampere Meterモードでは0.8～5.0 Vの外部電源が必要で、連続測定電流の上限は1 Aです。Source MeterモードでDUTが400 mAを超える電流を消費する可能性がある場合、NordicはPPK II用に定格1 A以上のUSB電源を追加することを推奨しています。これらは計測器の上限であり、デバイスの推奨動作条件ではありません。Nordicの最大DUT電流と電源に関する説明を参照してください。

flowchart LR
    A["設定済みの電源またはバッテリーエミュレーター"] --> B["電流測定器"]
    B --> C["製品の電源入力に定めた測定点"]
    C --> D["SF32デバイス、無線、使用するペリフェラル"]
    E["同じ測定点の電圧モニター"] -. "電流と同時に記録" .-> C
    F["分離したデバッグ／トレース用インターフェース"] -. "状態マーカーのみ" .-> D

各測定の前に、次の点を確認してください。

1. 計測器を迂回する経路や余分な負荷となる可能性のあるUSB電源、デバッガー、その他の電源を切り離してください。シナリオに必要なインターフェースだけを残します。
2. 選択した測定点に規定の供給電圧を印加してください。給電されているすべてのレール、ジャンパー、モジュール、外部デバイスを記録します。
3. 製品用ファームウェアと想定するPM構成を使用してください。最終測定では、出荷時の製品構成に含まれる場合を除き、大量の診断ログを無効にします。
4. 比較条件をそろえるため、スマートフォン、アクセサリー、テストアプリ、距離、アンテナの向き、RF環境を統一してください。
5. 測定時間を十分に確保し、繰り返されるBluetoothイベントを多数含めてください。捉えやすい単発のパルスだけでは不十分です。

BLEアドバタイズイベントの消費電力を段階ごとに見る¶

典型的なBLEアドバタイズイベントは、単一の無線パルスではありません。まず短時間の電源投入と準備を行い、高周波水晶発振器を起動して安定させます。電源とクロックの準備が整うと、予定された無線起動時刻までスタンバイ状態で待機します。ここで示すスキャン可能または接続可能なアドバタイズの例では、無線を起動し、プライマリアドバタイズチャネルの1つで送信した後、同じチャネルで受信ウィンドウを開きます。最初の2回の受信ウィンドウの後は、次のチャネルで送信する前にスタンバイへ戻ります。最後の受信ウィンドウの後には後処理を行います。非接続可能かつ非スキャン可能なイベントでは、要求を受信するウィンドウを開きません。実際の段階は、設定されたアドバタイズ種別とチャネルマップによって異なります。

図に示す全体の順序は、前処理 → 水晶発振器の立ち上がり → スタンバイ → 無線起動 → 無線送信 → 無線切り替え → 無線受信 → スタンバイ → 無線送信 → 無線切り替え → 無線受信 → スタンバイ → 無線送信 → 無線切り替え → 無線受信 → 後処理です。無線起動は最初に一度だけ行います。チャネル38と39での送信は、それぞれ直前の受信ウィンドウ後にスタンバイを経て始まります。この順序はNordicが示す典型的なBLEアドバタイズイベント図の段階に沿っています。これらは一般的なBLEイベントの段階であり、Nordic固有の無線状態ではありません。また、描き直しではほかの状態を追加していません。電流値と時間の比率は説明用で、SF32の実測値ではありません。実際の値は対象デバイスで測定してください。

この図は、プライマリチャネル37、38、39をすべて使う、スキャン可能または接続可能なレガシーアドバタイズイベントを示しています。要求を受信した場合の応答処理は描いていません。図中のチャネル番号は説明用です。Bluetooth Core仕様では、有効なプライマリアドバタイズチャネルのインデックスを任意の順序で使用でき、実際に使うインデックスは設定したチャネルマップで決まります。各使用チャネルでは最大1個のアドバタイズPDUが送信され、通常は各チャネルで1回ずつ送信されます。3回の送信は各チャネルへのパケットのコピー送信であり、確認応答を待った再送ではありません。スキャン可能または接続可能なイベントでは、規定された条件で要求を受信するためのウィンドウを設けますが、スキャン不可かつ接続不可のイベントでは要求受信用のウィンドウを開きません。Bluetooth Core 6.2のリンクレイヤー仕様とBluetooth SIGの入門資料を参照してください。拡張アドバタイズ、異なるチャネルマップ、または実際に要求を受信した場合は波形が変わることがあります。設定した動作は対象デバイスで確認してください。

SF32では、これらの段階名を波形上で各段階を識別するための目印として使い、Nordic固有の動作状態や時間・電流の既定値として扱わないでください。対象のアドバタイズ構成に受信動作が含まれるかどうかは、設定したアドバタイズ方式によって異なるため、実機の波形で確認してください。

イベント全体のエネルギーは、トレースの下の面積を電圧で重み付けしたもの、つまり各段階の電圧・電流・時間の積の総和です。

E_event = sum(V_stage x I_stage x t_stage)

一定の供給電圧では、周期的なアドバタイズ構成は次のように近似できます。

Q_event = sum(I_stage x t_stage)
I_average = (Q_event + I_idle x (T_cycle - t_event)) / T_cycle

Q_eventには、イベント内のスタンバイ期間を含む全段階の電荷量を算入します。t_eventはイベント全体の継続時間です。I_idleはイベントと次のイベントの間で測定した電流であり、イベント内のI_standbyとは区別してください。T_cycleは開始時刻から次の開始時刻までの実測間隔で、アドバタイズ遅延やスケジューリングの影響も含みます。間隔が変動する場合は、設定したアドバタイズ間隔を正確な周期とみなさず、十分に長い代表的な波形を積分してください。

電圧が一定なら、ある段階の実測電流または継続時間を2倍にすると、その段階のエネルギーも2倍になります。短いTX、RX、起動処理がイベントの主な消費要因になる一方、間隔が長い場合はイベント間のアイドル消費が平均電流を左右します。GPIOや処理負荷の小さいファームウェアイベントで各段階を識別し、製品全体の電源入力で測定してから最適化対象を決めてください。

Classic Bluetoothはプロトコルのタイミングが異なりますが、同じ測定の考え方が当てはまります。Bluetooth Core Specificationは、Inquiry ScanとPage Scanを別個のスキャン手順として定義し、Sniffを、Peripheral側の受信スロットを予定されたSniff機会に絞る、接続中のACLモードとして定義しています。相手機器のトラフィックによって、アンカー間隔を超えて無線動作が続く場合があります。これらはタイミング上の動作であり、電流値の見積もりではありません。対象デバイスで、設定したスキャンポリシー、Sniffパラメーター、実際の相手機器とアプリケーションの動作を測定してください（Bluetooth Core Specification: BR/EDR Baseband、HCI Scan Enable）。

モード固有の測定計画を構築する¶

「Bluetoothが有効」というだけで、単一の動作状態とみなさないでください。BLEとClassic Bluetoothでは接続手順や低消費電力動作が異なります。一方、デュアルモード製品では、無線サブシステム、コントローラー資源、クロック、メモリーに加え、アプリケーション処理も両モードで共有することがあります。まず再現しやすい単純なシナリオから測定し、その後、製品で実際に使う組み合わせ動作を確認してください。

SiFliのBLE/BT消費電力テストは、BLEのアドバタイズと接続に加え、Classic BluetoothのScanとSniffを確認できるため、基準測定に使えます。ただし、特定のボードで得た結果がそのまま製品仕様になるわけではありません。この例が対象とするボード、ウェイクピン、コンソール、PM設定を使って基準測定の再現性を確保し、その後、対象ハードウェアで製品のロール、相手機器、通信量、電源管理方針を再現してください。

BLEを単独の無線モードとして測定する¶

まずBLE単独から測定してください。Classic Bluetoothのプロファイル通信やモード間のスケジューリングが測定波形に重ならず、BLEの基準値を把握できます。

BLEのロール、ピア、接続またはアドバタイズパラメーター、送信電力、ペイロード、開始トリガー、終了条件、実際の使用頻度を記録してください。これらの事実がないトレースは、別のファームウェアリビジョンと比較できません。

Classic Bluetoothを単独の無線モードとして測定する¶

デュアルモード製品では、まずClassic Bluetoothを単独で測定し、その後でBLEを加えてください。こうすることで、BLEイベントが測定に混在せず、Scan/Sniff時の基準消費電力と各プロファイルに固有のシステム処理を把握できます。

Classic Bluetoothのロール、相手機器、Scan/Sniffの設定、送信電力、プロファイル、ペイロードまたはセッション時間、開始トリガー、終了条件、実際の使用頻度を記録してください。オーディオプロファイルでは、製品が実際に使用するオーディオ経路全体を測定対象に含めてください。

デュアルモード動作は独立したシナリオとして測定する¶

BLEの測定とClassic Bluetoothの測定を単純に足し合わせて製品のデュアルモード電力を計算しないでください。この2つのモードは、無線時間、コントローラーの処理、クロック、メモリー、アプリケーションのウェイクアップを共有し得ます。そのため、両者の組み合わせの結果は、2つの独立した平均値の算術的な和とは実質的に異なる場合があります。

flowchart LR
    A["デバイスのアイドル時基準値を測定"] --> B["BLE単独のシナリオを測定"]
    A --> C["Classic Bluetooth単独のシナリオを測定"]
    B --> D["製品で使用するデュアルモードのシナリオを実行"]
    C --> D
    D --> E["BLE、Classic Bluetooth、ホスト、ペリフェラルの処理を記録"]
    E --> F["実測した合計エネルギーを製品の電力予算に反映"]

BLEとClassic Bluetoothそれぞれの基準値を把握してから、デュアルモード製品を測定してください。例えば、Classic BluetoothでオーディオをストリーミングしながらBLE接続を維持する製品では、同じハードウェアとピアの条件で次のすべてを測定します。

1. BLE接続済みアイドルのポリシー単独。
2. Classic Bluetoothのストリームまたはデータプロファイル単独。
3. 想定するBLEトラフィックを含む、両モードを組み合わせた実運用時の定常状態。
4. 組み合わされた状態への出入りの遷移、加えてエラー復旧と再接続の挙動。

BLEイベント、Classic Bluetoothのプロファイル処理、アプリケーションのコールバック、オーディオ・データ処理、PM状態の変化をマーカーで識別してください。無線のスケジューリングと、それによって発生するシステム処理を分けて追えます。例えば、Classic Bluetoothのセッション中にBLEのコールバックが発生し、アプリケーションCPUがスリープに戻れない、といった予期しない相互作用を見つけやすくなります。

トレースをファームウェアの挙動と対応付ける¶

実機の消費電力を把握するには、測定トレースとファームウェアの処理を対応付けることが重要です。製品の処理の開始・終了をマーカーやログで記録し、電流が変化した理由をトレースから判断できるようにしてください。

• アプリケーションが開始した転送や通知バーストの前後。
• ディスプレイ、センサー、Flash、オーディオパス、その他の外部コンポーネントが有効化または無効化されたとき。
• ファームウェアがPM状態を要求したときと、デバイスが実際にその状態に入ったとき。
• 再接続、再試行、エラー復旧パスが開始したとき。

GPIOトレースポイント、処理負荷の小さいイベントマーカー、または再現可能なテストスクリプトを使用してください。シリアルログは立ち上げ時には役立ちますが、消費電力を変化させることもあります。最終測定では、ログ出力を測定に影響しない観測手段と見なさず、条件を管理する試験変数として扱ってください。

実際のエネルギーと日次消費量を計算する¶

電流や電圧が変動する場合は、その積を時間について積分してエネルギーを求めます。

E_scenario = integral(V(t) x I(t) dt)
P_average = E_scenario / T_scenario

測定点の電圧が一定なら、平均電流でも比較できます。それでも電圧の記録は残してください。特に、レギュレーター出力側と電池入力側の間で測定点を変える場合は重要です。

製品で繰り返し発生するシナリオから、1日の消費エネルギーを次のように求めます。

E_day = sum(E_scenario x events_per_day) + E_mode_idle + E_other_states

1日を重複しない時間帯に分けてください。E_mode_idleとE_other_statesには、各シナリオの総エネルギーに含まれていない時間だけを算入します。BLEとClassic Bluetoothが同時に動作する場合は、単独モードの測定値を足すのではなく、組み合わせたシナリオを実測します。24時間分のベースライン消費をすでに計上しているモデルでは、各操作の総エネルギーではなく、ベースラインを超える増分だけを加算します。電圧をV、電流をA、時間をsで計算すると結果はJです。Whへの換算は3600で割ります。

シナリオのエネルギーには、それを完了するために必要なデバイス全体の作業を含めなければなりません。例えば、スマートフォンの通知には、接続イベント、ホストの処理、センサーまたはFlashへのアクセス、ディスプレイの更新、スリープへの復帰が含まれるかもしれません。RFパルスだけを測定するとデバイスのエネルギーを過小評価することになり、トレースマーカーなしに製品全体を測定すると消費要因を特定できず、改善につなげにくくなります。

モデルと実機の測定結果を照合する¶

最初のモデルで主な消費要因に見当をつけ、実測値で更新してください。推定値と測定波形の差は、イベントの見落とし、時間設定の誤り、予期しない復帰動作、計上していない外部負荷を調べる手掛かりになります。

flowchart LR
    A["製品シナリオを1つ定義"] --> B["デバイスの電流と電圧を測定"]
    B --> C["トレース区間に印を付け、要因を特定"]
    C --> D["シナリオ完了あたりのエネルギーを算出"]
    D --> E["実際の1日あたりの使用頻度に換算"]
    E --> F["電力予算と比較"]
    F --> G["最大の寄与要因を改善"]
    G --> A

再現可能なSiFliの基準構成から始める¶

製品ファームウェアを測定する前に、SiFli-SDKの例を使ってBluetoothの状態を再現可能にしてください。例のサポート対象ボード、供給パス、ジャンパー構成、SDK設定、テスト手順は基準構成の根拠であり、製品仕様ではありません。

リリースレビューチェックリスト¶

• 測定境界と供給電圧が文書化されている。
• リリースに関連するすべてのシナリオについて、電流と電圧が記録されている。
• USB、デバッガー、UARTアダプター、外部モジュールの電源が管理されているか、明示的に含まれている。
• トレースがファームウェアのイベント、PM状態の要求、実際に入った状態と対応付けられている。
• 該当する場合、BLEのアドバタイズ/接続済みアイドルとClassic BluetoothのScan/Sniffの挙動が測定されている。
• 出荷される各Classic Bluetoothのデータまたはオーディオプロファイルに、定義され測定されたワークロードがある。
• デュアルモードのシナリオは、単一モードの結果を足し合わせて推定するのではなく、組み合わされた製品状態として測定されている。
• 該当する場合、代表的な転送、切断、再接続の挙動が測定されている。
• シナリオのエネルギーを現実的な1日の発生頻度に換算し、電池予算と照合している。
• 最大の寄与要因に担当者と、最適化または受け入れの判断がある。

関連リソース¶

• BLE、Classic Bluetooth、プロファイル、セキュリティ、システムの共存についてはBluetooth概要。
• Classic Bluetooth、BLE、LE Audioのプロジェクト選定についてはBluetooth SDKの例。
• PM設計と製品全体の電力予算については低消費電力設計の概要。
• コンポーネントから製品への検証ワークフローについては電力測定と検証。
• 実例に基づく日次使用エネルギーモデルについてはスマートウォッチの消費電力分析。

最終更新: 2026-10-19