2016/08/11

[nrf52]Centralしていく (4)

前回(3)は、on_ble_evt()でBLE_GAP_EVT_ADV_REPORTイベントを拾えば、Advertisingで何が来ているのかは読めそうだ、というところまでだった。


それでは、コメントアウトしていたところを復活させよう。
adv_report_parse()が成功した後の、UUIDを見つけた後の動作だ。

forで見つけたUUIDを検索して、0x180Dが入っていればスキャンを停止させている。
sd_ble_gap_scan_stop()が失敗するのはスキャンさせていないときくらいらしいから、通常はこのタイミングでエラーにならないのだろう(ユーザ操作による停止とクロスしたときとかかな?)。

 

一般的に、受信よりも送信の方が電力がいると思う。
しかし、送信は一瞬で良いけど、受信はタイミングがわからない場合、待ち続けないといけない。
nRF5xのPeripheralは、Advertisingをble_advertising_init()のble_adv_fast_intervalなどで設定した時間のうちに3ch分送信するようになっていたと思う。
Core v4.2の図を見ると、Intervalの頭でぽんぽんぽん、と3発打つようだ。

image

 

Centralではsd_ble_gap_scan_start()のintervalとwindowで指定するようだ。
intervalとwindowは2.5msec~10.24secの間で設定可能。
intervalが長く、windowが短くなると、消費電力は減るけどPeripheralを捕まえにくくなるんだろう。
このサンプルでは、intervalは100msec、windowは50msecになっているので、こういうイメージで良いのかな?

image

 

では、もしPeripheralのintervalが100msecだったら、タイミングがあえばCentralから捕捉できなくなるのだろうか?
あー、それを防ぐために、Advertising Intervalはこういう式になっているのか([Vol 6, Part B, 4.4.2.2])。

image

advDelayは0~10msecのランダム値なので、受信間隔と幅が固定でも、いつかは捕捉されるだろう、ということか。

image

AndroidとNFCペアリングしようとしても、デバイス名が出てくるときと来ないときがあるのは、このランダム性が関係しているのかも。


その後、スキャンパラメータのselectiveとp_whitelistを変更している。
この値はスキャン開始前に設定するのだが、ペアリングしているかどうかで値が違う。
スキャン後に設定する値は、ペアリングしていないときの値だ。
そして、sd_ble_gap_connect()で接続している。

selectiveビットが立っているなら、アドレスはNULL指定らしい。
だから、アドレスとしてスキャンしたものを使うためにselectiveを0にしているのだろうか?
だったら、p_whitelistはそのままでも良い気がするのだけど、これは「current active whitelist is to be used」が理由なのか。

 

わからん、わからんのだ・・・・。
Centralがどうやるとどう振る舞うのかがわかっていない。
multilink_centralやuart_cを見ると、スキャンパラメータは固定値だし。
はて、どうしたものか。。。

一旦忘れて、BLE接続した後の動作を見ることにしよう。


関係ない話だが、NordicのSDKサイトがInfocenter系になってから探しづらい。。
個人的には、SDKだけでもDoxygenの方が探しやすくて良かったのだけど、ローカルで良いから構築できないものだろうか。

0 件のコメント:

コメントを投稿

コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。