前回(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発打つようだ。
Centralではsd_ble_gap_scan_start()のintervalとwindowで指定するようだ。
intervalとwindowは2.5msec～10.24secの間で設定可能。
intervalが長く、windowが短くなると、消費電力は減るけどPeripheralを捕まえにくくなるんだろう。
このサンプルでは、intervalは100msec、windowは50msecになっているので、こういうイメージで良いのかな？
では、もしPeripheralのintervalが100msecだったら、タイミングがあえばCentralから捕捉できなくなるのだろうか？
あー、それを防ぐために、Advertising Intervalはこういう式になっているのか([Vol 6, Part B, 4.4.2.2])。
advDelayは0～10msecのランダム値なので、受信間隔と幅が固定でも、いつかは捕捉されるだろう、ということか。
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 件のコメント:
コメントを投稿
コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。
注: コメントを投稿できるのは、このブログのメンバーだけです。