[nrf52]Centralしていく (3)

前回、何もいないのにAdvertisingのログが出る、と書いたけど、そういえばテスト中で動かしっぱなしにしているのがいるのを忘れていた。
それに、近くでAppleTVを持っている人がいるのか、それらしいAdvertisingもスニファで見えていた。

 

スニファと言えば、nRF51 DKをスニファとして使うというのは、ありなんじゃないかと思い始めている。
受信するだけだからだ。
まあ、送信する機能もある装置なのにどうよ、という気もするのだけど、その辺は信じてください、としか言いようがないな。

nRF52 Preview DKをスニファにしてみたのだが、まあまあ動いた。
数字を入力するタイプのペアリングを行うと、どうもうまく拾えないのだ。
まあ、まだ正式なnRF52用のFirmwareが出てないし、そもそもPreviewだしねぇ。

TIのスニファも、ペアリングのときからパスキーを打ち込んでいても途中で止まるのだ。
"TI ペアリング"で検索しても「ティファニーチタンペアリング」が出てきてガックリしたので、本題に戻ろう。

---

前回は半分寝ながら書いたので、もう一度。

出ているのは、BLE_GAP_EVT_ADV_REPORTイベントのログ。
typeが2と3のログが出ているが、これはまずtype=2で試して、だめだったら3で試す、という方式をとっているからだ。

2は、«Incomplete List of 16-bit Service Class UUIDs»。
3は、«Complete List of 16-bit Service Class UUIDs»。

IncompleteでもCompleteでもいいから、16bitのService UUID、つまりBluetooth SIGに登録されている一般的なUUIDがあるかどうかを見ているのだろう。

HRSのPeripheralでは、Complete Listを使っている。
0x180D(Heart Rate)、0x180F(Battery)、0x180A(Device Information)の3つだ。
services

---

Advertisingのデータは、Length, Type, Valueの並びだ。
Lengthは自分を含まない長さで、1byte。
TypeはAD Typeで、1byte。
たとえば、<<Flags>>は中身が1byteなので、Lengthは0x03、Typeは0x01だ。

BLE_GAP_EVT_ADV_REPORTイベントが来ると、p_ble_evt->evt.gap_evt.params.adv_reportにデータが返ってくるようだ。
型はble_gap_evt_adv_report_tで、こうなっている。

typedef struct {
  ble_gap_addr_t peer_addr;
  int8_t         rssi;
  uint8_t        scan_rsp : 1;
  uint8_t        type     : 2;
  uint8_t        dlen     : 5;
  uint8_t        data[BLE_GAP_ADV_MAX_SIZE(=31)];
} ble_gap_evt_adv_report_t;

あれ、typeって2bit分しかないの？と思ったが、そうではなくてBLE_GAP_ADV_TYPESの値とのこと。
なるほど、Advertisingの種類ということですな。
scan_rspが0のときだけ有効とのこと。

dataは31byteだから、ADV_INDなどのペイロードが全部入っているのだろう。
adv_report_parse()ではそれを頭から見ていって、typeが一致したらペイロードのアドレスとデータ長を返す、なければNOT_FOUNDを返す、という作りになっている。

 

今コミットしているソースだと、検索しているだけで、実際にそれを使うL.376～をコメントアウトしているから、次はそれを見ると良いだろう。

とりあえず、このくらいのソースでAdvertisingのスニファくらいはできるということはわかった。