2014/12/29

[nfc]NFCの復習

NFC(Near Field Communication)の復習をしよう。
定期的にやらないと忘れそうだからだ。

NFCは、企業主体で進んでいる規格だと思っている。
なので「これがNFCだ!」というものは特にない。
以下は私の主観なので、「思う」とか「考えている」とかは省略するが、全部に点いていると思ってもらって問題ない。
技術と金融が密接になっているので、切り離して考えられないのだけど、私は金融関係がさっぱりわかってないから推測が多分に入ってしまうのだ。

「NFC」と大ざっぱに書いているけど、時代や文脈によって少し意味合いが異なることがある。
(おっと、スポーツのNFCは別としてだよ。)
興味ある人は少ないと思うが、私の主観で書いていくので、物事の見方の1つと思ってもらえると幸いだ。


NFCの歴史

日本では、FeliCaが大半を占める。
海外では、Type-AやType-Bがほとんどだ。

Type-A、Type-Bという呼び方は、規格で言えばISO/IEC-14443の呼び名になる。
これは日本工業規格で言うところの、JIS-X6322にあたる。
14443はNFCに関する最初の国際規格だろう。
14443-1~4まであるのだが、ここではひっくるめて14443と呼ぶ。

Type-AとType-Bは、周波数のような大きなところは同じなのだけど、物理的な方式は異なるし、プロトコルも異なる。
なのになぜ同じ規格になっているかというと、近接通信という統一した規格書を作ろうとしていたからだと思う。
企業としては、Type-AはNXP,Type-BはMotoloraらしい。
聞いた話によると、ここにType-CとしてSonyのFeliCaを入れ込もうと努力していたけど、Suicaというセキュリティを含んだ方式にしようとしていたので仕様公開できずに断られたとか何とか。
実状はわからないけれども、とにかくISO/IEC-14443にFeliCaは組み込まれなかった。
これが「FeliCaは日本仕様」と呼ばれてしまう原因じゃないかと思ってる。
Wikipediaでは、2008~2011年になっているが、初版はまだ早かったと思う。
ISO/IEC 14443
ISOサイトにはISO/IEC 14443-1:2000があったから、15年くらい前には存在していたことになる。

image

 

「あ~あ、FeliCaは入れてもらえんかった~」で終わらせられるわけもなく、経緯はよく知らないが、Type-AとFeliCaがまとまった規格ができた。
それがISO/IEC 18092。
これには別称があり、それが「NFCIP-1」。
ここで初めて「NFC」という単語が出てきた。

image

その後、ISO/IEC 15693という規格ができた。
・・・ごめん、それよく知らない・・・・・。
そして、それらを全部取り込むようなISO/IEC 21481ができた。
WikiPediaによれば、ここまでで2005年になったようだ。
近距離無線通信 - Wikipedia

image

これじゃあいかんね、と思ったかどうかは知らないが、"NFC Forum"という規格団体を作り、そこで商業的なNFC規格をまとめよう、ということになったようだ。
N-Markのようなマークのわかりやすさや、認証制度なども行っているので、私はNFC Forumで謳っているものを「NFC」と呼んでることが多い。

image

まあ、人それぞれだと思うけどね。


ひとやすみ

便宜上、「FeliCa」と書いたが、正確にいえば違うことになる。
NFCの場合、金融関係と一緒に成長してきたこともあり、セキュリティを除外できない。

例えば、Suicaには交通の記録やチャージした金額情報なんかが載っているけど、「チャージした料金が勝手に書き換えられると困る」というのは同意してもらえるだろう。
いや、書き換えて偽造できたらうれしいとかは抜きとしてね・・・。
でも、チャージされている料金を確認したいだけなのに、JRの駅内に行ってユーザ情報を入力しないといけない、となると不便な人も多かろう。

ここら辺のアクセスできる・できないがセキュリティの分野になる。
そしてセキュリティにはコスト、つまりお金のかかりかたも出てくる。
Suicaとかは薄いカードでできてるけど、これに指紋認証とかネットを経由した認証方式とか採用するとどうなるか。
薄くできないし、電源がいるし、認証するためのサーバとか何とかもろもろかかる。
「それができるようになってから販売しろよ」と思う人がいるかもしれないが、今の技術では現実的ではない。

NFC Forumの中でも、今のところセキュリティのところは対象外になっている。
まあ、仕方ないんだけどね。。。
NFC-Aもいくつか種類があるけど、セキュリティ有りの製品も多いし。
(いかん、抜き出すと図が日本列島っぽくなってしまった・・・)

image

NFCのセキュリティは企業としての肝だから、規格には取り込めないだろうと思ってる。
そこを破壊しかかっているのが、HCE,Host Card Emulationだ。


NFCでセキュリティを破られでもしたら、もう大ごとである。
FeliCaがISO/IEC 14443で渋ったのもそこだろうから、仕方ない気はする。
(NXPはどこまで公開してるんだろう?)

それに、FeliCaが国際的に載らないのには、国際規格のこともあると思う(Featured Content » Smart Card Allianceだっけ?)。
確か、USIMにSecureElement(SE)を載せる方式を推奨する、とかだったような。
FeliCaは今のところOnBoardタイプのSEしかないので、海外では使われなかったんだと思う。

SEは利権というか、一種の不動産みたいなもののようだ。
特にOnBoardタイプはそうだと思う。
SIMにSEが搭載されたタイプを使ったことがないので何とも言えないが、OnBoardタイプのSEを持った機種から別の機種に移動するのが大変なのはわかると思う。
移動できないわけではないが、キャリアの手を使わないと移動できないと思う(昔のFeliCaは移動できなかったかもね)。
SEがSIMに載っているなら、SIMだけ別の機種に載せればよいだけだ。

もしかすると、SEがSIMに載らないということで、端末自体の値段が安くなるのかもしれない。
あるいは、アドレス帳みたいなSIMへのアクセスと競合するのを嫌ったのかもしれない。
単になんかコンプライアンスか何かあるのかもしれないけど、移動はしにくいと思う。
GSMAとかの団体は、そういうのをやらせたくないような気がする。


仕事でやってるわけじゃないので、あんまり推測だけ書くのはやめておこう。
変な雰囲気になるのはやだからね。

私が嫌なのは「FeliCaは日本仕様だからだめだ」みたいな流れになることだ。
理解されない技術は魔術と同じだ、みたいな言葉が昔からあるが、よっぽどの新技術でも無い限りは、理屈がわかれば理解できるものである。
だから、聞いて理解できないものについては反発を覚えるし、反発しないといけないだろうと思っている。
その反発は、その技術に反発するのではなく、技術を理解できないことに対する反発だ。

時期的に(2014年12月)、STAP細胞がどうのこうのという季節になっている。
残念ながら、私では内容を理解できない。
できないけど、検証とか再現性とかはどの分野でも同じなので、気にはしている。
(ああ、バグとかもそういえば同じようなもんだな。)

一応、このブログは政治的なものには関与しないつもりだし、芸能関係にも関与しないつもり。
その観点で行くと、STAP細胞の件は、意図的にデータを作ったのであればNG、そうじゃないならOK、としか言えない。
もうちょっと言えば、これはマスコミがやーやー言ってしまったから表面化しただけであって、「自分が期待するような実験をして」「自分が期待するような結果が出た」という論文を作って発表して、ちょうど通ってしまっただけなんじゃないかという気がしている。
よいことじゃないんだけど、別に今さら騒ぎ立てることでもないような・・・。

なーんとなくだけど、マスコミが勝手に騒ぎ立てて神輿に乗ったけど、はしごを下ろされてしまってあたふたしてる、という気がしますな。
ちっせぇ。

この件は、マスコミがいなくても正常化されてるような感じが、なんとなくですが、しますな。
学生が卒業するために書こうと、お金もらって博士が書こうと、論文は論文なんだけどね。


と、Yahooニュースの情報だけで書いたけど、「よくわからん」ということしかわからんかった。
私が知りたいとしたら、こんなところかなぁ。

  • 意図的かどうか
  • 意図的なら、何人が行ったのか
  • 意図的ではないなら、どのくらいの確率で発生しそうか

意図的だったら、個人か集団かが気になる。
個人でも気になるけどさ。。。
うーーーん・・・・

とりあえず、うちのサイトでは技術の取り扱いはこうかな。

  • よい技術は、よい
  • よい技術を持つ人が、よい人とは限らない
  • だめな技術は、だめ

よいものはあれこれできるけど、だめなものはだめですわ。
残りはがんばってもらうしかないですな。

2014/12/19

[uml]ユースケース図がうまく描けない

以前から、ユースケース図がうまく描けないという自覚がある。
普段作るような自分用ツールだと、自分で仕様を決めて作るだけなので必要性はないのだけど、お仕事だと曖昧なところがあると困るので、使えるものは何でも使いたい。

自分で書いていて思うのは、油断すると変に細かく書きすぎてしまう、ということだ。
例えば、いま作ろうとしているBLEとFeliCa Plugをつなげたようなシステムは、こんな感じだ。

image

これは、かなりがんばって削ってみた結果だ。
その少し前は、「搬送波を・・・」とか「割込が・・・」とか、要求仕様と機能仕様と実装観点がごちゃまぜになっていたのだよ。

 

なんでそうなるかというと、何を作りたいのか私もよくわかっていない、というところがあるか。
ハードのところや、ミドルのところまで、アプリも少しは考えているんだけど、全体として「何をやりたいか」が決めきれていないのだ。
今回で言うと、使うのはBLEとFeliCa Plugなんだけど、そこから出た最初の企画が「BLEとFeliCa Plugをつなげてみたい」で、それ以上のものが何もないのだ。
「FeliCa Plugだから、相手はNFC R/Wしかない」とか「とりあえずスマートフォンにはつながないとな」とか、そういうぼんやりとした考えしかないのが、ユースケース図にも現れているような気がしてならない。

よくある例だと、自動販売機。
使う人は「商品を買う」が目的なので、それをユースケースにする、という紹介があった。
うーん、これは自動販売機というものの仕様がかなり確定してからじゃないと出てこない気がする。
それまでは、要求したい仕様自体の洗い出しを先にやるのかね。

2014/12/17

[ble]Serviceの位置

気になることがあると、そっちをある程度調べるまで気が済まないので、なかなか進まない。。
ともかく、WireSharkの件も私の中では落ち着いたので、BLEを普通に使ってみよう。

「普通に」というのは、今までが「BLEのサービスを使ってみる」をやっていた状況に対してのものだ。
何かをするためにBLEを使う、というのをやりたい。
まずは以前動かしたことのある、FeliCa Plugをつないでみようと思う。

何をするか考えてはいないが、軽く設計をしておこう。

image

ま、まずはここからだ。
ほら、山の上から麓を見下ろすような気分で設計しないと、ね。

FeliCa Plugと接続するのが目的なので、ServiceはFeliCa Plugのミドルから使える階層にした方がよいのかとも思ったが、ミドルに引っ付け過ぎすぎるのもどうかな、と思い、アプリ経由でしか通信できないイメージにした。


そういう設計のことを考えると、凝集とか結合とか、そういう話が出てくる。
が・・・苦手なのよね、その手のものが。

とりあえず、直接関係ないものは分けておこう、くらいでよいと思う。
あと、関係あるものはまとめておきましょう、かな。
マイコンの性能が上がってきたおかげで、ずいぶんと余裕あるコーディングができるようになってきたものだ。
まあ、苦手なことには変わりが無いんだけどね。


さらに関係ない話になるが、こういうレイヤーを図にするときの、私の中の配色ルールが決まっていないのが気になっている。
今のところ、アプリが暖色系で、ハードに近くなるほど寒色系、みたいなイメージでやってる。

あとは、濃淡とか。
背景が濃い方がよいか、前景が濃い方がよいか、とか。

image

今回はExcelで作っていて、Excelの標準で持ってる効果を使っている。
補色にするようなシーンでもないと思うので、同じレイヤーは同系色がよかろうと思う。

他の人はどうかな、と、Androidのアーキテクチャ図を見てみた。

http://developer.android.com/images/system-architecture.jpg

私とは逆で、アプリが寒色、ハードが暖色みたい。
背景と前景はグラデーションの方向が逆で、前景はそこまで暗くならないようにされてるみたいだ。

こういうのも参考にしながら、自分の配色を決めたいものだな。

2014/12/16

[ble]CC2540 USB Dongleから直接WireSharkで見る

WireSharkでリアルタイムの流れが見えてもしょうが無かろう、などと言っていたが、だんだん気になってきた。
もしかして、私は技術的に難しそうだから逃げただけじゃないだろうか。。。
えぇい、作ってしまえ!

というわけで、luaを作った。
https://sites.google.com/site/hiro99ma/ble/files/ble_cc2540dongle.lua?attredirects=0&d=1

USB CC2540 Dongleのポートを見て、WireSharkのBT LE LLプロトコルに流しているだけだ。
あんまり動かしてないけど、Advertisingくらいは取れていそうだ。
フィールドとかは気にしないでおくれ(練習の消し忘れ)。

短いluaファイルなので大したことないのかもしれないが、ここまで至るまでが大変だったのだ。
特に、BLEのDissectorをどうやって指定するのかがわからなくてね。。。
UDPとかTCPはやり方がよく出てくるけど、DissectorTable.get()の引数がわからんかったのだ。
メニューの「Internals > Dissector tables」で一覧は出てくるけど、BLEっぽいのがないし、検索もできない。
やむなく、1つ1つツリーを開いて探し、ようやく見つけた次第だ。

最後は、Dissectorに渡すサイズがどこから計算してよいかわからず、いくつかパケットを見て、-10すればよさそうだ、という手抜きで済ませてしまった。

 

まあ、一番の問題は、単にUSBのバルク転送を見ているだけなので、何でもかんでもBLEのデータだと思ってしまうところだろうな。

2014/12/14

[ble]NotificationはATT_MTU-3まで

勘違いしていた、というお話。

データ量を多くしたかったので、256byteのAttributeを作った。
読み出しの方では256byte読めたのだが、Notificationだと20byteまでしかできていない。

image

sd_ble_gatts_hvx()に渡している値も確認したが、256byteになっている。
なぜだ・・・。

そこでようやくCore_V4.1を確認した。
Vol.3 Part F "ATT"の"3.4.7.1 Handle Value Notification"。
読むと、先頭からATT_MTU-3までが上限とのこと。
nRF51822というかS110というか、とにかく今はATT_MTUは23byteなので、20byteまでというのは仕様通りだ。
なるほどねぇ。

それ以上のデータが読みたいならRead Brob Requestを使えとのこと。
つまりまあ、Notificationだから通知だけが目的ってことですな。

[nrf51]GNU ARM Eclipse Plug-ins

nRF51822をJ-Link LITEでデバッグしている。
うちはEclipseでやっているのだが、私がGDBに詳しくないので、なんとなくで使っている。
まあ、BLE通信しているときはステップ実行してもすぐに死んでしまうので、ブレークポイントとウォッチが使えれば問題ないのだが。

ただ、止めて、死んだあとの対処がよくわかっていなかった。
FLASHに焼かずにリセットしたいだけなのだけど、手順がわからない。。
しばらくは、Loadしないデバッグ設定を別に用意してたんだけど、本当に焼いてないのか不安が残った。

調べると、GDBコマンドでリセットできそうだった。
monitor reset
monitor halt
こんな感じでコンソールに打つと、リセットしているようだ。

そして、慣れてくると手で打つのも面倒になってきた。
なんか方法はないだろうかと見てみると、J-Link plug-inなるものがあることがわかった。
http://gnuarmeclipse.livius.net/blog/jlink-debugging/

インストール方法はこちら。
http://gnuarmeclipse.livius.net/blog/plugins-install/

これを使うと、右クリックに「Restart」が出てきて、コマンドを打たずに済むようだ。
また、今まであれこれしないとmainに止まってくれなかったりする件が解決されていそうな気がする。
よかったよかった。

 

J-Linkのプラグインだけじゃなく、OpenOCDのもあるようだ。
他にもコンパイラやテンプレートなんかも提供されているので、気にしておきましょうかね。

2014/12/13

[ble]どうせならWireSharkで直接パケットを見られないだろうか

なんか、いつものことながら、道を外れつつある・・・。
いや、人の道は外れないけど、やろうとしてたことを外れるというか。
まあ、より道は子供の頃から楽しいものだから、仕方あるまい。

前回、PSDファイルをPCAPに変換してWireSharkで見る、という作業を行った。
接続の構成は、こんな感じ。

image

ソフトまで含めると、こうなる。
前回やったのは、黒い矢印のところだけ。

image

WireSharkは「ネットワークインターフェース」のデータを取り扱うソフトなので、ネットワークインターフェースじゃないものは扱うことができない。
だから、BLEのデータもWireSharkで見ることができないから、一度PSDファイルにしたものをWireSharkで読めるPCAP形式に変換してみた、というのが前回の話だ。

 

だから、ネットワークインターフェースで見えるようにさえしてしまえば、どんなデータもWireSharkで見ることができる、というのもまた真である。
今回で言えば、CC2540 DongleとPC間はUSBで接続されているので、USBの通信をネットワークインターフェースで見えるようにすればよいだけのことだ。
「USBはネットワークとは別だろう」と思うかもしれないが、そんなことを言ってしまうと「ネットワークのデータは画像データじゃないじゃないか」と言ってるようなもので、ノイマン型コンピュータの中で生きている我々にとっては「データはメモリに載っかってしまえばみんな同じ」なのだ。
あとは、どう扱うか、だけ。

WireSharkもそれをわかっていて、USBを解析する方法が書かれている。
私はWindowsだったので、USBPcapを使ってみた。
tourのStep1~3で、Dongleのデータをpcapファイルに保存し、WireSharkで見てみた。
うん、Bulk転送でそれっぽいデータが受信できている。
Dongleの操作はWireSharkではできないので、これはTI Packet Snifferで操作した。
Step4のlive captureも同じ要領で試して、それっぽいデータが受信できていた。
(USBPcap2となっている箇所は、自分のスニファしたいUSB Host番号に合わせること!)

あとは、これをリアルタイムで解釈するようにがんばるかどうか。。。
この記事を書き始める前までは、LUAでプラグイン書いてやってみよー、と思ってたんだけど、今のところリアルタイムのWireSharkで見る必要性がほとんどないのだな。
自分でスニファアプリを作ったとかすれば必要になってくるけど、今使っているBVMCNDT52はUSBを電源供給で使うだけなので、そういうのがいらない。COMポート経由とかでも同じことはできると思うけど、そんなことを考えるのが面倒だからDongleを買ったのだよ。

そんなわけで、「TIのドングル出力を直接WireSharkで見られるか?」という問に対してはYesなんだけど、「今からがんばりたいか?」という問に対してはNo、と答えてしまうな。

[ble]TI Sniffer(BLE)のPSDファイルをpcap形式に変換

TIのBLE Sniffer Dongleを使っている。
解析してくれるので重宝するのだが、フィルタのかけ方がよくわからない・・・。
WireSharkだったら何とかわかるのだが、と思って検索すると、Zigbeeの変換をしているツールがあった。
説明を読むと、どうやらPSDファイルのフォーマットは公開されているようだ。
ならば、BLE版を作らねばならぬのぅ。

swru187g.pdfというのが、そのドキュメント。ユーザーズマニュアルだ。
パケットの種類によってデータ構造が若干異なり、ZigbeeとBLEも異なっていた。
この資料と、pcapのフォーマットを見ながら、ごにょごにょと作成。

cygwinで動いたので、先日インストールしたVisual Studio community 2013でビルドした。
gccとの互換性が高く、#pragma packも含めてまるまるビルドできた。
(tchar解決が面倒だったので、unicode指定は外したが。)

2014/12/13 18:35 GUI版も追加しました(.NET Framework4)
https://sites.google.com/site/hiro99ma/ble/files/psd2pcap.zip?attredirects=0&d=1

第1引数にpsdファイル、第2引数に出力ファイル名を入れるだけ。
WireShark 1.12.2で確認した。
プロトコルはWireSharkに入ったものを使っているだけなので、Link Layerまで。
自分用にやりたければ、ここからLUAでプラグインを書くとよいんじゃなかろうか。
とりあえず変換できたというレベルなので、そこまで調べてない。

チャネルとRSSI値を「Bluetooth Low Energy RF Info」のところで見えるようにしている。
PSDに入っている値をそのまま放り込んでいるだけなので、妥当な値なのかどうかあんまりわかってない。

気が向いたら、C#でGUI版も作ってしまいたいところだ。


気が向いたので、作って同じZIPファイルの中に突っ込んだ。
C#は使い慣れていないので、「構造体にデータを突っ込んで、パディング無しにして全部書込む!」みたいなやり方がわからず、素直に1データずつ書込んでいった。
まあ、データがメモリ上にどう展開されるのかを考えながら実装する方が今では異端なのかもしれんな。

2014/12/11

[nrf51]Notifyを受けられるようにするとSYS_ATTR_MISSINGが起きない

先日、こんなのを書いた。
hiro99ma blog: [nrf51]BLE_ERROR_GATTS_SYS_ATTR_MISSINGが起きる

このときはBlueLightだとエラーにならないのよねぇ、で終わった。
しかし、少しいじってみたのだが、どうもnRF Master ControlでもNotifyを受け付ける状態にしてから送信すると、エラーが発生しないのだ。

ということは、BLE周りのドライバとかがどうのこうのではなく、Notifyを受けると設定したときか、Notifyを受ける状態にしてNotifyを受けたときのどちらかで、Peripheralに返す値が違うようになって、SYS_ATTR_MISSINGが発生しなくなったと考えるのが妥当だろう。

 

そこまではわかるけど、このBLEスニファで調べるのは非常につらい。
WireShark形式にログを変換してくれるようなしくみがあれば、検索などがやりやすいんだけど。

[android]Android Studio 1.0がうちでも動いた!

以前、こんな記事を書いた。
hiro99ma blog: Android StudioがうちのWin8.1(32bit)+2GBメモリでヒープが足りんらしい

あれこれ試したつもりだったけど、ダメだったのだ。
「統合開発環境なんて!」と切り捨てたい気持ちもなくはないが、ツール無しで開発できるとはとても思えない。
それに、今後はEclipse環境はこのまま置いていかれそうなので、いずれは移行せねばなるまい。

ええぃ、やってしまえ!
と、以前の環境を全部捨てて、Android Studio 1.0をインストールした。
そうすると・・・あっさり動いた。
エラーも出ない。
ビルドしても、エラー無し。
デバッグとかまではやっていないけど、今までだめだったところが動いている。
なんだったんだ・・・。

まあ、過去は過去、今は今。
以前の設定が悪かっただけかもしれないけど、正式版で動くことが確認できたので満足だ。

2014/12/10

[nrf51]BLE_ERROR_GATTS_SYS_ATTR_MISSINGが起きる

BLEの対抗機をNexus5にして、調査を進めることにした。
調査といっても、転送できるデータ量を増やしたいというだけのことだ。
ちゃちゃっとやって次に進もうと思ったのだが・・・ASSERTが発生した。
(ASSERTが発生すると、LEDが点灯するようにしている。)

やったのは、ボタンを押すとNotifyで256バイトのデータを送りつける、という動作だ。
1バイトの時には何もなかったのに。。。

エラーコードは0x3401。
BLE_ERROR_GATTS_SYS_ATTR_MISSINGらしい。
「System Attributes missing」とあるが、はてさて・・・。


検索すると、すぐ出てきた。Nordicの資料なので、ログインしていないと見えないのかも。
GATTS Handle Value Indication or Notification with System Attributes Missing

なんとなく見覚えがあると思ったら、以前調べていた。
hiro99ma blog: [nrf51]BLEスタックのイベントハンドラを見る (6)

一番最後に「サンプルでは、このエラーが発生すると、単にエラーという扱いにしている」と書いているとおり、私もエラーにしている。
sd_ble_gatts_sys_attr_set()を呼んでやりさえすればよいようなんだけど、疑問が残る。

  • なぜサンプルではsd_ble_gatts_sys_attr_set()を呼ぶようにしていないのか
  • なぜイベントとしてではなく戻り値でエラーを返すルートがあるのか
  • なぜ送信データが多くなった場合に発生したのか

これを調べる前の想像では、Notifyで送信しているデータを送信しきっていないのにsd_ble_gatts_hvx()を呼んだからじゃないだろうか、と思ってたんだが、どうなんだろう?
だって、「System Attributeが見当たらない」というのは、データ量に依存しなさそうではないか。
また、IndicationやNotifyのときにわざわざこのエラーを返すというのは、何かしらSystem Attributeと通知の関連が深いことを意味しているのだと思う。
それに、通知のためのインターフェースなら"hvx"などというよくわからない単語は使わないでよいはず。
"send_notify"とか、もっとわかりやすい言葉があるだろうに。

このあたりの理屈がわかることで、BLEかnRF51についての理解が深まるんじゃないか、と勝手に期待している。
では、1回で終わるかどうかわからないが見ていこう。


正常時のシーケンスによると、sd_ble_gatts_hvx()によってATTテーブルを更新し、それによってSoftDeviceがピア側に通知するようだ。
エラーを返す場合、ATTテーブルは更新されない。
だから、sd_ble_gatts_hvx()を呼んでSYS_ATTR_MISSINGが返ってきたときには、sd_ble_gatts_sys_attr_set()を呼んで終わりではなく、またsd_ble_gatts_hvx()を呼ばないと行かんはず。

 

"hvx"は、GATT HVx、らしい。
Core_V4.1を検索したが・・・High quality Voice、くらいしか相当しそうなものが無かった。
と、思ったらNordicの造語か。
what does "HVx" stand for ? [closed] - Nordic Developer Zone
"Handle Value x"で、xは"Indication or Notification"とのこと。
わかるかー。

 

次はSystem Attribute Missingとの関係か。
検索すると出てきた。
nRF51 SDK: Bluetooth Low Energy Pairing Guide
このNordicドキュメント、SDK4, 6, 7にはなく、SDK5に入っている。。。
バージョンごとに入っていたりいなかったりすると、どうしようもない。

大ざっぱに読んだ感じでは、System AttributeというのはGATT Server側が接続しに来たClientごとに持っておくようなデータで、切断前にFLASHに保存するようだ。
Bonding Managerが管理するようなので、Just WorksのBonding無しとかだと関係ないような気がするな。

あ、Bonding有りにしてた・・・。
しかし、無しに戻しても同じエラーが発生した。


よくわからないので、BlueLightを使ってみたら、こっちはエラーにならなかった。
クライアント側の問題??
でも、そこから続けてMaster Controlを使ってもエラーにならなかった。

普通の無線通信だから、パケットを拾って比較していけば違いはわかるんだろうけど、その根気が私にあるかどうか。
接続開始のチャネルが毎回変わるので、スニファで拾うのが大変なのよね・・・。
受信機を3つ用意すればいいんだけど、そんなブルジョアジーなことはしたくないし。

2014/12/08

[nfc]Android5にはWiFi設定をタグに書き出す機能がある

こんな記事があった。
Android 5.0に対応したスマホ・タブレットなら「かざす」だけでWi-Fi接続がスグ可能に! - IO DATA

Android標準でできるということは、独自のフォーマットじゃなくて、Static Handoverでやってるんじゃないだろうか。

ネットで調べると、これが引っかかった。
Android "L" Feature Spotlight: Write Wi-Fi Passwords To NFC Tags Directly From Android
(日本語がわかる身としては、右上のTwitterにリンクしているアイコンが怖い・・・。)
考えてみれば当たり前ではあるが、タグに書き出す機能も標準で入っていた。
WiFi設定のところで、書き出したいSSIDをロングタップするとメニューが出てくる。
image


タップするとパスワード入力画面が出るので、SSIDのパスワードを打ち込む。
image


そうするとタグに書き込めるようになる。
image  image

タグをタップさせたら終わり。
image  image

読込むときは、タグをタップするだけ。
ダイアログが出てきて確認を求められるので、接続をタップすると接続できる。
image


はじめてAndroidの設定をするときはWPSが使えなさそうなので、タップでできると便利なのだが、どうだろうね。

 

タグの方だが、ざっと見た感じでは、やはりStatic Handoverで使う形式っぽい。
パスワードも平文なので、共通で使う場所のようなパスワードが広まっても問題が無いところで使うのがよいかな。
公衆Wi-Fiなんかは向いてそうだ。

2014/12/07

[ble]Nexus7(2013)できれいに動かない

なんとなくGATTがわかって気になってきたので、とりあえずnRF51822を動かしてみることにした。
送受信できるデータサイズを256byteまで増やして、どんな感じか見てみようとも思ったのだ。

が、Connectしてからの動きが何かおかしい。
いつの間にか勝手にAdvertisingに戻ってしまうのだ。
BLEスニファで見ていくと、通信が止まっていた。
サイズを増やしたことが原因かとも思ったが、そうではなさそうだ。

これを試していたのがNexus7(2013) + Android5.0 + nRF Master Controlだったので、iPad mini(old) + LightBlueで試してみた。
うん、問題ない。
じゃあAndroidがよろしくないのかと、Nexus5 + Android5.0 + nRF Master Controlで試してみた。
問題ない。

・・・ということは、Nexus7(2013)で動きがよろしくないということか?
ソフト要因かハード要因かはわからんが、あまり気にしたくない部分なので、当面はNexus5を使うようにするか。

2014/12/06

[ble]ATT_MTU

Core_V4.1によると、AttributeのPDUはこんな構成になっている。

image

 

図に注釈を付けると、こんな感じだ。

image

 

じゃあ、ATT_MTUはどういう値なんだろう?

これは、GATT(Vol. 3 Part G)の5.2章に書かれていた。
デフォルト値は23で、これは"not less than the default value"と書いてあるので、下限値のようだ。
つまり、デフォルトでのAttribute Paramsは22oct。

MTUのサイズを知るために、Exchange MTU Requestなるものがある。
Requestを投げるのはClient側で、まず自分の受信可能なMTUサイズ(Client Rx MTU)を投げる。
そのResponseとして、Server Rx MTUが返ってくる。
どちらもサイズが2octなので、65535byteまで可能・・・なのかしら?
しかし、これは「私はこれだけしか受信できませんのであしからず」というご挨拶なので、相手ができないことをできるようにするわけではない。
なので、1回に送る量が23octより大きくできる、という期待はしない方がよいだろう。

Packet index: 226
Length: 23
Raw data (hex): 58 AF 2C EB 0A 0E 0A 00 04 00 05 01 47 00 02 29 48 00 01 29 CE B4 D0
RSSI [dBm]: -58
CRC OK: 1

SensorTagのパケットを受信して、23byteのものを見てみた。

image

違う・・・。
これは、L2CAPも含んで23byteだ。
こういうのもあった。

58 AF 2C EB 0A 1B 17 00 04 00 09 15 49 00 0A 4A 00 00 00 00 00 00 00 00 B0 00 40 51 04 32 AA 00 F0 27 36 FF

image

これは、ATT Lengthが21byte(0x15)なので、ATT_MTUがデフォルトだったなら最大長になる。
青文字の範囲がATTだ。
ということは、それより外側はL2CAPになるのかな。

いやあ、バイナリが読めるようになってくると、興奮してきますな。


あれ・・・最後の一言だけで、よい記事のはずが台無しになった気がする。

 

s110/ble_gatts.hでは、こうなっていた。
23byte固定だそうな。
/** @brief Only the default MTU size of 23 is currently supported. */
#define GATT_RX_MTU 23

 

同じファイルに、ATTの最大データ長定義も書かれていた。
実は、これを探してたのだ。

[ble]GATTが少しわかった気がする

hiro99ma blog: [ble]GATTがもやもやしてよくわからない

あれから2ヶ月が過ぎた。
少しは進化したんじゃないかと思う。


ATTとGATTの関係

GはGeneralのG、なのだ。
あまり深く考えていなかったが、Attribute(以下、ATT)の使い方を一般化しましょう、そしてそれを共通ルールとしてしまいましょう、という意味のGeneralだ。

ATTの構成は、こう(Core_V4.1より)。

image

こういう入れ物があるので、それに論理的な意味を付けるのがGATTの役割だ。
それがつまり、Characteristicだの、Serviceだのになる。

Characteristicが持つプロパティの、WriteだとかIndicateだとかも、GATTの話だ。
ReadOnlyとかWRとかは、ATTの話になる。

 

GATTとAdvertisingの関係

関係ない。
Advertisingは接続する前の段階の話で、GATTは出てこないのだ。
ここはL2CAPが主にやっているような気がする。

 

GATTとGAPの関係

GAPは、いろいろ。

よく見る、CentralやPeripheralみたいなRoleはGAPだ。
これはL2CAPのMasterやSlaveと関連している。

StandbyやAdvertising、Connectionのような接続もGAPだ。
実際にやるのはL2CAPみたいだが。

Bondingのこともあるかと思えば、Securityも入っている。もちろんGATTも。
なんかもう、「GAPとはこれだ」という定義ができなさそうだ。
あえてつけるなら、GAPはBluetoothプロトコルスタックだ、みたいな感じになるんだろうか。。。


まあ、あんまりここは突っ込まなくても、プロトコルスタックは実装されているものを使うから、任せておけばよいだろう。

2014/12/02

[vs]ビルド結果のコンソール出力に慣れない

日本語化したVisual Studio Community 2013で、以前作っていたSDK for NFC Starter Kitのビルドだけやってみた。
動くかどうかは別として、まずはビルドできないと不安ではないか。

結果としては、特に問題なくビルドできた。
問題は無いんだけど、そういえばビルド結果のコンソール出力をいつになっても見間違えて慣れない、ということを思い出した。

========== ビルド: 1 正常終了、0 失敗、0 更新不要、0 スキップ ==========

ソリューションのビルドを行ったので、プロジェクトごとに成功・失敗が出るんだと思う。
それはわかっているのだが、どうしても「ビルド:1」と読んでしまうのだ。。。
だから、その次は「正常終了、0」と見てしまい、ええっ!とあせってしまうのだ。

なんでだろうか?と少し考えてみたが、たぶん「正常終了」が単位だと認識できていないからだろう。
gccとかだと「1 errors」みたいな結果なので、たぶんこれはそのまま日本語にしたのだろうが、なんかねー、なんかねー。

2014/12/01

Visual Studio Community 2013をインストールしてみた

してみただけだ。

image

ExpressをインストールしたままCommunityをインストールしたが、特に怒られることもなかった。
が、紛らわしくなりそうなのでExpressはアンインストールすることにした。
インストールも時間がかかるから、余裕があるときにやるとよいだろう。

 

インストールすると、コントロールパネルのインストールしたアプリ一覧が増えていた。
かなり増えていた。
数えると、40以上も何かしらインストールされているようだった。
Windows Phone SDKなんかも入ったけど、これはいらないなぁ。。。

アンインストールしようとしたが、候補に出てこなかった。
よく見ると、MFCが使えるんだな。
Visual Studio6で作ったプロジェクトは、まだ読めるだろうか・・・。

image


日本語言語パックは、これのようだ。
英語慣れするためにも、なるべく開発環境は英語のまま使うことが多いのだけど、Visual Studioはメニューが多くて探すのが大変な気がするから、日本語にしておこう。
本当は、日本語になったのを確認してからブログをアップしようと思ったが、日本語パックのインストールを始めてから30分経っても終わらないので、あきらめた。
違ってたら、すまん。
http://www.microsoft.com/ja-jp/download/confirmation.aspx?id=40783

 

そういえば、Visual StudioってリボンUIじゃないんだな。
やっぱり無理、とか思ったんだろうか。