いままでBLEのPeripheralしか作っていなかった。
受ける側のCentralはスマートフォンに任せておけば良いだろう、と思っていた。
が、通信がうまく行かないことがあって、無線状況が原因では無さそうな感じがした場合、それが誰のせいなのかよくわからない。
スニファで見られるときは良いのだけど、TIのドングルはペアリングしていると接続後に途中でパケットが見えなくなってしまうようなのだ。
スマートフォン側のログを見ても、全部出るわけじゃないし、なんでそういうことになったのかまではわからない。
なんとなくドライバが原因のような気はするのだけど、もしかしたらPeripheral側がちょっとよくないのかもしれない。
こういう、Peripheral側にも原因があるのではないかという不安を払拭するためには、もっと信頼性の高いCentralが必要だ。
お客さんに「たぶんスマートフォンのBLEドライバ周りが原因だと思うんですけど。。。」と語尾を濁すのには疲れたのだ。
nRF Connectのデスクトップ版が使えるとよかったのだけど、nRF52 DKのようなNordicが出している基板じゃないと動かないようだった。
nRF51822がいくつかあるので、それでCentralを回せば良いのだけど、どうもS130はIC revisionが3以上ではないと動きを保証してくれないようなのだ。
じゃあ、nRF52832でやろう。
今回は、サンプルを動かすだけの紹介だ。
評価ボードは、太陽誘電さんのEBSHCNZXZを使う。
nRF5 SDK v11.0.0のexamples\ble_central\ble_app_hrs_cを使う。
「_c」は、Centralだと思うが、もしかしたらHRSのclientという意味かもしれない。
gcc版で試しているが、特に難しいことはなく、PCA10040でmakeするだけでよい。
これをEBSHに焼いて起動する。
USBはシリアルポートとして見えるので、TeraTermなどでつないでおく。115200bpsだ。
そうすると起動時に「Heart rate collector example」が出力される。
あとは、HRSのPeripheralを動かすだけだ。
今回はnRF51822のHRSサンプルをS110上で動かした。
そうするとペアリング(たぶんJust Works)して、取得した値をシリアルポートで見ることができる。
あっさりだ。
シリアルに出力されるのはAPPL_LOG()の内容で、デバッグ情報のAPPL_LOG_DEBUG()はそのままでは出力されない。
Makefileに「-DDEBUG」などとしてDEBUGマクロを有効にしておくと、nrf_log.hが使えるようにしてくれる。
ペアリングさせないようにSEC_PARAM_BONDをどちらも0にしたけど、DM_LINK_SECURED_INDのルートを通るな、うーむ。。。
まあ、ともかく、サンプルは簡単に動かせることがわかったので、中身を見ていこう。
0 件のコメント:
コメントを投稿
コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。
注: コメントを投稿できるのは、このブログのメンバーだけです。