単なる広告Beaconは1つの問いにしか答えません。「このタグはどこにあるか?」です。そこにセンサー(温度・湿度・加速度・光)を加えると、同じハードウェアが「ここはどんな状態か、何か変化したか?」に答える分散測定ノードになります。本記事では、センサーBeaconの背後にあるエンジニアリングの決定——センサーのインターフェース方法、31バイトの広告ペイロードへの読値の詰め込み、サンプリング頻度がバッテリー寿命をどう左右するか、オンデバイス閾値ロジックが単なるブロードキャスターをエッジ検出器に変える仕組み——を解説します。

1. センサーBeaconが異なる理由

位置のみのBeaconは、固定ペイロードを固定間隔で送信します。消費電力は決定的でファームウェアは自明です。センサーBeaconは以下を行う必要があります:

1. センサーをスリープから起動(または低電力サンプリングモード維持)

2. 読値を取得(I2C/SPI経由、数ミリ秒+センサー静止電流を消費)

3. 値を処理(フィルタリング、較正、閾値チェック)

4. 送信内容を決定——生値か、差分か、あるいは何も送らないか

5. 符号化して広告

各ステップが遅延と電流を追加します。設計上の問題は、1時間に数回以上サンプリングすると通常センサーサブシステム(無線ではなく)が電力予算を支配するため、測定忠実度とバッテリー寿命のバランスです。

2. センサーインターフェースと消費電流

大半のBeaconセンサーはデジタルバスにぶら下がります。2つの一般的な選択肢:

インターフェース 速度 典型センサー電流 起動遅延 備考
I2C 100-400 kHz アイドル1-15 µA、アクティブ100-500 µA 1-5 ms 2線、アドレス制限、共有容易
SPI 1-8 MHz アイドル2-20 µA、アクティブ200-800 µA 0.1-1 ms 4線、高速、低遅延

コイン電池Beaconにとって支配的なコストはアクティブ電流ではなくサンプルあたりのエネルギー=(起動遅延+変換時間)×平均電流です。10 msを300 µAで消費する湿度センサーは1読値あたり3 µCです。1時間に1回なら3 µC/h ≈ 0.83 µA平均——無視できます。1分に1回なら50 µA平均——これで無線と競合します。

2.1 一般的なセンサーとフットプリント

センサー 典型品 バス アクティブ電流 変換時間 出力範囲
温度 TMP117 I2C 3.5 µA 15.5 ms(平均) -0.1〜0.2 °C
湿度 HDC2080 I2C 300 µA 1.2 ms ±2 % RH
3軸加速度 LIS2DH12 I2C/SPI 4 µA(低電力) 1 ms ±2/4/8/16 g
環境光 OPT3001 I2C 1.8 µA 100-800 ms 0.01-83k lux
気圧 LPS22HB I2C/SPI 25 µA 13 µs(ODR) ±0.025 hPa
CO2(NDIR) SCD40 I2C 18 mA(パルス) 0.5-5 s 0-40000 ppm

CO2センサーは際立っています:18 mAは無線のスリープ電流の1000倍であり、コイン電池で連続動作できません。これはセンサー選択が電力アーキテクチャを制約する理由の典型例——CO2 Beaconにはより大きな電池か有線電源が必要です。

3. 31バイトへのセンサーデータ符号化

BLE広告パケットは31バイトのペイロード(レガシー)を運び、AD構造に分割されます:1バイト長、1バイト型、その後データ。iBeaconは25バイトのメーカーデータを使用、Eddystone-URLは約20バイト。センサー用の余地は少ししかありません。

3.1 「追加せよ、置き換えるな」の原則

位置システムのための識別フレーム(iBeacon / Eddystone-UID)をそのまま維持し、センサーデータを運ぶセカンダリ広告フレームを追加します。BLEは複数の広告フレーム間で切り替え(各広告イベントごとに交替)を許可します。数秒間3チャネル全てをスキャンするゲートウェイは両方を捕捉します。

3.2 Eddystone-TLM:組込みテレメトリチャネル

Eddystone-TLMはテレメトリを運ぶ標準準拠の方法です:

フィールド バイト 内容
バージョン 1 0x00
電池電圧 2 1 mV単位、0-65535
Beacon温度 2 8.8固定小数点、°C
PDU数 4 通算パケット数
稼働時間 4 0.1 s単位

TLMはきれいですが限定されています:1つの温度値、電池のみ、湿度/加速度なし。より豊富なデータにはカスタムメーカー固有データ(MSD)フレームが必要です。

3.3 カスタムMSD符号化例

マルチセンサーBeacon用のコンパクトなパック配置(リトルエンディアン):

バイト0:    会社ID LSB(Appleは0x4C、または割当てCID)

バイト1: 会社ID MSB

バイト2: フレーム型 = 0x50(ベンダーセンサーフレーム)

バイト3: センサービットマップ(bit0温度、bit1湿度、bit2加速度、bit3光、bit4電池)

バイト4-5: 温度、8.8固定小数点、符号付(×256)

バイト6-7: 湿度、8.8固定小数点(×256)

バイト8-9: 光、10ビット対数スケール(0-1023 → 0.01-100k lux対数)

バイト10-11:電池 mV(0-65535)

バイト12-13:加速度大きさ、8.8固定(g × 256)

バイト14: ステータス/フラグ(モーション検出、閾値発動)

バイト15: シーケンス番号(0-255で折り返し)

この16バイトフレームはiBeacon識別フレームと併存し、余裕があります。ビットマップによりBeaconは不在センサーを省略し、ペイロードを縮小できます。温度のみのBeaconはバイト0-7(8バイト)を送信、全センサーノードは全16バイトを送信します。

3.4 圧縮のコツ

  • 差分符号化:絶対値ではなく最後の読値からの変化を広告。1時間に0.1 °Cドリフトする温度は符号付8ビット差分(±127 × 0.01 °C)に収まり、16ビット絶対値の代わりになります。
  • 浮動小数点より固定小数点:8.8固定小数点は2バイトで±127.99を0.004 °C分解能——環境監視に十分。
  • 対数スケール光:`encoded = round(1023 × log10(lux/0.01) / log10(100000/0.01))` は5桁を10ビットに圧縮。
  • ランレングススキップ:ノイズフロアを超える変化がなければ、全サイクルではなくNサイクルごとにハートビートフレームを送信。

4. サンプリング戦略と電力予算

バッテリー寿命への最大のレバーはサンプリング頻度です。3つの戦略:

4.1 固定周期サンプリング

最も単純:T秒ごとにサンプリング、各読値を広告。

平均電流 ≈ I_radio_adv × duty_adv + I_sensor_avg × (t_sample / T)

T = 60 s、t_sample = 5 ms、I_sensor_avg = 200 µAの場合:センサー寄与 = 200 µA × 5ms/60s = 0.017 µA——無視できます。無線(例:スリープ1 µA、3 msを15 mAで1秒ごと)は約45 µAで支配。つまり1分に1回サンプリングではセンサーはただ;1秒ごとに押し上げるとセンサーコストは約1 µAに上昇——まだ小さいが無視できなくなります。

4.2 適応型/オンデマンドサンプリング

識別フレーム用に遅く(例:5分ごと)サンプリングしますが、加速度計の割り込みでモーション時にMCUを起動させます。ウェイクオンモーション・モードの加速度計は約1-4 µAを連続消費しますが、何か起きるまで無線アクティビティを排除します。モーションが稀な資産追跡では、平均電流を10-100倍削減します。

4.3 閾値トリガー・バースト

Beaconは沈黙(ディープスリープ、<1 µA)し、値が限界を超えるまで——冷凍庫が0 °C超、2 g超の振動、ドア開——待機します。トリガー時に:

1. 完全起動

2. 高レートでNサンプルのバーストを捕捉(イベント特徴付け用)

3. ピーク値+タイムスタンプ付きアラートフレームを広告

4. ディープスリープへ復帰

これがエッジ・インテリジェンス・パターン:Beaconは*何を*言うかだけでなく*話すべきか*を決定します。平均電流はスリープフロア+まれなバースト電力に崩壊します。

4.4 電力予算の実例

コイン電池CR2032 = 225 mAh = 810 C。目標寿命2年 = 17.5 k時間。

コンポーネント 電流 デューティ 平均
nRF52スリープ 0.6 µA 99.9% 0.6 µA
無線広告(3 ms @ 15 mA、1/2 s) 15 mA 0.6% 90 µA*
センサーサンプリング(5 ms @ 200 µA、1分に1回) 200 µA 0.0008% 0.017 µA
加速度計ウェイクオンモーション 2 µA 100% 2 µA
合計(周期) ~92.6 µA
合計(閾値、99%沈黙) ~2.6 µA

*無線が周期モードを支配。閾値トリガーに切り替えると合計電流は35倍低下し、寿命は約2.5年から数十年に延びます(電池自己放電が限界に)。

5. オンデバイス・フィルタリングとトリガーロジック

全ての生読値を送信すると帯域とバッテリーを無駄にします。Beaconはフィルタリングすべき:

  • デッドバンド:|値 − 最終送信| > Δ(例:0.3 °C)の場合のみ広告。ノイズ駆動のチャタリングを抑制。
  • 移動平均:デッドバンド比較前に4-8サンプルを平均し単一スパイクを除去。
  • 変化率:d(値)/dtが傾きを超えるとトリガー(例:5 °C/分の温度降下=圧縮機故障)。
  • ヒステリシス:別々の進入/退出閾値を使用(例:>0 °Cでアラート、<-0.5 °Cでクリア)し境界でのアラートフラッピングを回避。

最小状態マシン:

状態: IDLE

タイマーティック時:

v = read_sensor()

v_f = lowpass(v)

if |v_f - last_sent| > deadband:

advertise(v_f); last_sent = v_f

if v_f > high_thr and 状態 == IDLE:

状態 = ALERT; advertise_alert(v_f, reason=HIGH)

if 状態 == ALERT and v_f < low_thr:

状態 = IDLE; advertise_clear()

このロジックはnRF52で1 ms未満で実行され、無線に対して無視できる電流を消費します。

6. 実際の導入パターン

6.1 コールドチェーン監視

ワクチン冷蔵庫の温湿度Beacon。5分ごとサンプリング、デッドバンド(0.2 °C)または閾値(>8 °Cアラート、<-0.5 °Cヒステリシス付きクリア)で広告。ゲートウェイが時系列を記録、侵害でプッシュ通知。バッテリー:CR2477(1000 mAh)で5分サンプリングで3年以上。

6.2 予測保全振動

モーターに取り付けた加速度Beacon。ウェイクオンモーションで、モーター稼働時のみ1 kHz振動バーストを捕捉。窓のRMS加速度が軸受摩耗を示す。週次RMS傾向比較(ゲートウェイ計算)で崩壊前に故障予測。電力:加速度計の2 µAアイドルが支配、CR2032で1-2年。

6.3 スマートビル占有検知

各室の光+PIR(またはmmWave)Beacon。光レベル+パッシブIRがカメラなしで在室を提供。Beaconは占有状態変化(入/出)のみを広告、連続luxは送らない。平均電流はPIRの約5 µA静止電流が支配——AAパックで数年。

7. ゲートウェイ側の考慮事項

ゲートウェイはカスタムMSDフレームを理解する必要があります。実用温水点:

  • 3チャネル全てをスキャン:センサーフレームは識別フレームと交替、両方捕捉には2-3広告間隔以上のマルチチャネル滞留が必要。
  • ビットマップを解析:存在するセンサーのみデコード、未知フレーム型は優雅に無視。
  • シーケンス番号処理:欠落フレーム(seqのギャップ)を検出し不確実リンクをフラグ。
  • 時系列格納:InfluxDB/TimescaleDBへ書込み、Beacon自身は履歴保持せず。
  • 較正オフセット:デバイスごとの較正定数をサーバー側適用(各センサーにバイアス)。

8. 落とし穴

  • I2Cバスロックアップ:クロックを見逃したセンサーがSDAをローに保持しバスを凍結。起動ごとに回復シーケンス(SCLを9回トグル、STOP送信)を追加。
  • コールドスタート・オフセット:TMP117は15.5 ms平均変換必要、速すぎるサンプリングは古いデータを返す。t_convを尊重。
  • 電池電圧の温度代理:多くのBeaconがV_battを報告するが、負荷下で電圧が落ちる——精度のため休息後のみ測定。
  • RH結露:HDC2080は結露で100 % RH読取、ゲートウェイは持続100 % RHを有効読値ではなく故障としてフラグすべき。
  • 広告衝突:センサーフレーム追加でエアタイム倍増、高Beacon密度で衝突確率上昇(広告衝突記事参照)。センサーフレームは短く、可能なら別広告間隔に。

9. 設計チェックリスト

  • [ ] セルに収まる電流のセンサーを選ぶ(コイン電池で18 mA CO2を避ける)
  • [ ] セカンダリ広告フレーム使用、識別フレームは位置用に維持
  • [ ] 固定小数点+ビットマップでパック、緩やかなドリフトは差分符号化
  • [ ] チャタリング抑制にデッドバンド+ヒステリシス設定
  • [ ] 固定高速サンプリングより閾値/ウェイクオンモーション優先
  • [ ] 起動ごとにI2Cバス回復追加
  • [ ] MSDレイアウトを文書化しゲートウェイが解析可能に
  • [ ] データシート代表値ではなく測定スリープ電流で電池モデル検証

10. 結論

センサーBeaconは単なる送信機ではなくエッジデバイスです。エンジニアリングの価値はオンデバイスで下された決定——いつサンプリングするか、いつ沈黙するか、何バイト送るか最小——にあります。固定小数点パック、ビットマップ駆動ペイロード、デッドバンドフィルタリング、閾値トリガーバーストにより、コイン電池Beaconは意味のある時にのみ話しながら、数年間環境状態を報告できます。

ボトルネックは無線ではなく、センサー電流とサンプリング頻度でした。ウェイクロジックを最初に設計せよ。広告符号化は簡単な部分です。

Comments

No comments yet. Why don’t you start the discussion?

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です