[nrf52]Centralしていく (2)

nRF52832＋S132でCentralを試していくシリーズ。

BLE接続させたくないを動かしてみよう。

---

立ち上げて、HRSのPeripheralを動かすとこういうログが出てきた。

[on_ble_evt]BLE_GAP_EVT_ADV_REPORT
[adv_report_parse]type=2
[adv_report_parse]type=3
[on_ble_evt]BLE_GAP_EVT_ADV_REPORT
[adv_report_parse]type=2
・・・

まず、最初のADV_REPORTは、ここだ。
on_ble_evt()でイベントを受けるのは、Peripheralと同じだ。
まあ、PeripheralでAdvertising中はon_adv_evt()なので、違うといえば違うのだが、Central目線で考えると妥当な気がするのだ。

 

BLEのPeripheralとCentralは、ネットのServerとClientの関係とちょっと違うように感じてしまうのだ。
ネットのHTTPサーバには、ブラウザというHTTPクライアントが接続しに行く。
BLEだと、PeripheralにCentralが接続しに行く。
だから、PeripheralがServerで、CentralがClientになることが多い。
データの提供元はだいたいセンサで、センサはPeripheralになっていることが多いからね。

なんとなくだが、データを集める方がサーバという気がしてしまうのだ。
クライアントがアップする、ということが多いからだろうか？
しかし、データを提供する方がServerで、もらう方がClientだから、いくらファイルサーバなどと名乗っていたとしても、データを提供するのはセンサだから、データを集めるファイルサーバはクライアントになるのだ。

言葉遊びみたいになってしまいますな。

---

さて、ログに戻ろう。

下からADV_REPORT通知が来て、adv_report_parse()を呼んでいる。
これはローカルな関数で、データがある限り解析をしているようだ。

そのtypeは、2と3だけだ。
2が"BLE_GAP_AD_TYPE_16BIT_SERVICE_UUID_MORE_AVAILABLE"で、3が"BLE_GAP_AD_TYPE_16BIT_SERVICE_UUID_COMPLETE"だろう。

typeの定義値は、ble_gap.hにある。
値は、Bluetooth SIGのAD Typeと一致するようだ。
adv_report_parse()の実装からすると、受信したAdvertisingデータの中で指定したtypeがあったら解析してくれ、というやり方のようだ。

まあ、30バイト前後のデータだから、それでよいのかもしれない。
それに自作ではなく汎用のUUIDなので、この程度のチェックでよいということかもしれない。
自作だったら、Advertisingデータもある程度固定になるので、その内容までチェックしたいはずだ。

---

今日はこれまでだ。

まだわからないこととして、Peripheralを検知したあと、Peripheralの電源を切ってもイベントが来続けているのだ。
単に、コメントアウトのしかたがまずかったのか、来るのが普通なのかで実装が変わってくるだろう。