(1)AndroidのHCEだが、サンプル通りに作ったり、ネットで見た通りに作ったりしているが、とにかく動作確認ができない。Beamを無効にするAPIがあるので、それを使ってR/Wにすればよいよ、とある。hiero_adgjmptwさんのスライドもあり、これを見ればAndroid側は間違えずに済むだろう。やってみよう、と思ったのだが、今月は私の手元にNexus7(2013)が1台だけしかないことを忘れていた・・・。あきらめるのもなんだし、そもそもうちにはPaSoRiという立派なR/Wがあるのだ。これを使わない手はなかろう。Kitでやることにした。Type4Aがどんなのかわからないにしても、ライブラリがうまいことやってくれるだろう。ベースは、以前作ったライブラリで良いだろう。https://github.com/hirokuma/NfcStarterKitWrapいくらType4Aといえども、元はNFC-Aだ。ポーリング動作については変わらないはず。C#で新規プロジェクトを作り、追加で既存のプロジェクトを選び、NfcStarterKitWrapを選択。フォームにボタンを1つつけ、イベントハンドラを用意する。}}そして、NfcStarterKitWrap.csのdetectNfcA()という関数があるので、ブレークポイントを張る。最初にエラーチェックがあるので、そのあとがよいだろう。止めようとしているのは、NFC-Aを検知したときのコールバック関数。Nexus7をかざすと止まるだろうか?・・・・止まった。NFCID1は4byte。ATSサイズは5バイトらしいのだけど、ATSって配列は1byte分しかない。SEL_RESは0x60、SENS_RESは0x0400。SENS_RESは、NFCID1のサイズなんかを表している。SEL_RES(SAK)はかざしたタグの特徴。昔整理した表だと、こうなっていた。14443-4(RATS+PSS)、のようだ。Request、のことらしい。Selection、のことらしい。おっ、いったか?いや、念のために、HCEサービスを止めて試しておかねば。かざしてみると・・・止まった(;_;)。Beamを止めたとしても、LLCPとかは動いてるんだろう。Nexus7(2012)だとNFC-FでしかLLCPなどをしていないように思っていたのだが、手元にないので自信がなくなってきた。R/W側ももうちょっとちゃんとType4Aとしてのシーケンスを流してやらないと、HCEが動いているかどうかの確認はできなさそうだ。windows2013/12/08[nfc]nfc.scサービス最初に書いておきますが・・・1時間くらいかけて調べながら書いた後、ネットに上げようとしたら「保存できません」と言われて、泣く泣く再起動しました・・・。nfc.scは、ブリリアントサービスさんのサービス。ベータ版だからか、ブリリアントサービスさんのページからは飛べなかった。NFCの開発者ブログもそうだけど、こういうのって難しいですな。仕事と結びつくなら経費割り当てて更新するけど、会社ブログの1つとなると、効果が見えにくいし現場の人は忙しくて更新が怠りがちになる、という。更新する前に(きっと)文面のチェックとかもあるだろうから、その文面をチェックする人も忙しくて・・とか、なんかいろいろと想像してしまう。新しいサービスを始めたのにホームページに載ってなかったら、「あら、中で何があってるんだろう」なんてあらぬ想像をしてしまったり。いうのは置いておくとしよう。nfc.scのページだが・・・。何ができるページか、まとまったところがわかりづらい。「開発したい」のところだろう。FAQのページもあるのだが、NFCでできることとnfc.scでできることが混ざっている。これは、大項目を分けた方がよいだろう。あと、規約的なページは、それぞれ別個にしないと、利用者に嫌がられると思う。更新日もわからないと、利用する側としては使いづらいか(利用する側は、サービス提供側のルール変更が困ると思う)。メニューの順番も「使いたい」と「開発したい」がわかりづらいか。nfc.scは「開発者向け」と書いているのに、先に「使いたい」と書かれると誰向けなのかわからん。βだろうとなんだろうと、使う人へはサービスを作ったサイトでやるだろうから、このページを経由するのは考えにくい。思えば、「使いたい」メニューは不要なんじゃないかと思う。「開発したい」の下にぶら下げるか、メニューの順番を右にずらすか。nfc.scでできること、という内容がどこに書かれているかわからなかった。大きく、提供してくれるのは2つのサービスだ。私みたいに、アプリの実装は何とかできなくもないけど・・・という人には非常にありがたい。NFCを使う利点は、基本的にユーザが「かざす」という操作をしたことを受け取れることだ。画面をタップしても同じことはできるんだけど、それを「タグを読む」という動作でやることで、いくつかの制約が生まれてくる。タップした端末の情報がわかる端末の位置情報がわからなくても、タグ側に位置情報があれば伝えられる制約というか、端末の情報取得ができるって方になってしまったな。情報抜き取りは嫌われるし、情報取得の制限はOSでできそうだけど、タグに書いてある情報を伝えるというくらいはできるだろう。駅・・・いろいろ範囲はあるので、説明して、範囲を選んでもらえればよいのではなかろうかね。情報の提供範囲が狭くなると、サービスの提供ができなかったり、他の人と同じサービスを受けられなかったりするだろうけど、もう、どうしようもないのではなかろうか。自分の情報がどのくらいの価値になっているかもわかるだろうし。「無料」ってのが、何を提供して無料になってるかは、知っておいた方がよさそうだ。便利そうではあるが、どうしたらよいのか、というのが今のところの印象だ。クラウドとかに詳しければ使ってみるかもしれんが、使う側としてはライブラリがあったとしても、その前にドキュメントがないと使うのが怖いのかも。1つ実例を挙げた方が良いのかも。前回、周波数ホッピングの計算について調べた。Nexus7でキャプチャできなかったのは、このホッピングがアルゴリズム通りになっていないからではないか?という推測があるんだけど、どうなんだろう。チャンネルマップを取得するCONNECT_REQを見比べよう。(WiFiなし)WiFiの有無でHopが違う!と思ったが、どうもランダムっぽい。p.2207によると、5~16のランダム値とのこと。チャンネルマップは違うようだ。これはAPIレベルなのか、OSレベルなのか・・・。アプリで意識するものでもなさそうだから、OSというかドライバというか、その辺でやってるんじゃなかろうかね(調べてない)。あと、タイムアウトってのも違うみたいだ。iOSは720msで、Androidは7000ms。これがconnSupervisionTimeoutで、教えてもらったところでは「切断と判断する時間」らしい。Androidがunusedにしているチャネルも調べておこう。9~18chに相当するはずなので、2422~2438MHz(2426MHzはAdvertisingの38ch)。ここに何があるのか・・・。いろんなものとぶつかっているので、今さらそこだけ避ける具体的な理由が思い当たらん。通常のBluetoothとかかなぁ・・・。http://www.ekouhou.net/%E5%91%A8%E6%B3%A2%E6%95%B0%E3%82%92%E9%81%B8%E6%8A%9E%E3%81%99%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E5%8F%8A%E3%81%B3%E6%96%B9%E6%B3%95/disp-A,2012-530455.htmlなんにせよ、キャプチャできないんだから、アルゴリズム通りになってないかどうかって判断できないんだな・・・。ble[ble]BLEのホッピングBluetoothは、1つの周波数を使って通信するのではなく、ある程度の範囲の周波数をチャネルに区切り、動的にチャネルを切り替えながら通信を行うらしい。これを「ホッピング」などと呼ぶそうだ。わかっていないので、調べておこう。Core_V4.1[pdf]が出てるけど・・・まだCore_V4.0[pdf]の資料で見ていきます。BLEは、チャネルが40(0~39)ある。39chはAdvertising専用。残りの0~36chがデータ通信用。p.2199)RFのチャネル番号と、Data/Advertisingのチャネル番号は異なるようだ。以下は、Data/Advertisingのチャネル番号で表現しよう。channel用の2種類に分かれている。channel用のPDUになる。channelは37個あるが、それは状態を持っているようだ。状態のテーブルがあって、"used"とか"unused"とかが割り当てられている感じがする。次に使うチャネル番号を決めるときは"unused"となっているものの中から選んでいくけど、37回やると全部"used"になってしまうから、計算式で計算されたチャネル番号の状態を"unused"に戻していく。algorithm」と呼んでいるのだろう。Classification」に説明があった。map」と呼んでいるそうだ。used=使ってよい、unused=使うな、という意味か。channelsの最小数は2、とある。最低でも2ch分は空いていないといかんということか。このmap情報は、Link層が管理していて、masterが用意し、slaveはそれを受けとって使うそうだ。数式としては以下の2つだけだ。(2)"unmappedChannel"は、現在のところ未割り当てになってるチャネル番号。上記の計算で、次に未割り当てにするチャネル番号を決める。"lastUnmappedChannel"は、文字通り、最後に「unmapped」にしたチャネル番号で、最初は0。1イベントが終わったら、式(1)でunmappedChannelを計算する。channelとして使う。状態が"unused"だったら、式(2)でremappingIndexを計算。この"remappingIndex"は状態のテーブルとは別で、"used"になってるチャネル番号のものを集めたテーブル用の番号だ。channelとして使うことになる。訳してみたが、あってるだろうか?実際に計算してみよう。37チャネルでやると大変だから、5チャネルにしてやってみるか。hopIncrement=1にしておこう。usedまず、最初はlastUnmappedChannelが0なので、0chを使う。used0chが終わったので、計算。used1chが終わったので、計算。2あら大変、2chは「unused」だ。このときは式(2)を使う。4chremappingテーブルの2番目は4chなので、次は4chを使う。used4chが終わったので、計算。そんなわけで、ホッピングするチャネルを知るためには、masterからslaveに渡されるチャネルマップとhopIncrementを取得すれば良いことになる。PDUなるものがあるらしいので、見ておこう。これは接続時のものなので、Advertising用のPDUだ。p.2207)ここの、ChMとHopがそうだ。5octで40bitだから、それぞれに1/0を立てていくんだろう。最初が1Fだから、3bit分抜かれている。Advertising用だろうな。Endianだから、先頭のb7~5ビットに0が入っているのだろう。hopIncrementは8。32、ときて、次は40だけど37でmoduloして余りが3だから、3ch。うん、解釈は間違ってないようだ。ble[ble]WiFiを切ったらキャプチャできたが、納得できん前回の続き。SensorTagとNexus7間の通信をうまくキャプチャできない件について。結果として、できるようになったみたいだ。Snifferのキャプチャが、途中で止まるAdvertisingは取れているconnectすると、しばらく取れている数秒以内に正常なキャプチャができなくなる。取れるのはエラーのときだけ。oldのときは問題ないので???だ。わからんかったので、FacebookのWF-BTLEというグループに聞いた。いくつか推測してもらって、その中に「AndroidのWiFiが邪魔してるのでは?」というのがあった。そんなことがねぇ、などと疑いつつもやってみると・・・取れるじゃないの奥さん!詳しい人だなあ、と思って見てみると、http://reinforce-lab.github.io/の人だった。oldでうまくキャプチャできているところにNexus7を近づけたら同じ現象が起きるはず、とやってみたが、こいつはうまくいっている。うーん、これはこれで納得がいかない。教えてもらったところでは、L2CAPで使えないチャネルをスキップするという情報交換ができるらしい。それが機能していて、CC2540Dongleもそれを使っているのかいな。Androidではそれを無視して送るとか・・・でもアプリは取れてるし・・・。スニファがBLEで使うチャネルを同時にすべてスキャンできてキャプチャするなら関係ないんだろうけど、たぶんそんなことはできないだろうから、そういう推測になるかなあ。できるんなら、Advertisingだけ取れて、connectしたら3分の1の確率でしか取得できない、なんてことはないはずだ。次に調べるのは、BLEがどうやってホッピングしているか、というところだろう。次はこのチャネル使います、という指定をしないと、うまく取得できないはずだ。ble2013/12/05[ble]うまくキャプチャできてない眠たいので、画像だけ。old)とSensorTagちょっと乱れてるけど、だいたい取れてそうだ。2013)とSensorTagまともそうに見えるが、最後はぐちゃぐちゃだ。画面左下にパケット数が出ているが、AndroidはぐちゃぐちゃになってからはCRCエラー時のパケットしか出てこず、パケット数はあまり増えていかない。iOSだと、順調に増えている。うーん、この違いは何だ?ちなみに、Android/iOSで動かしているアプリは、どちらもTIから取ってきたものだ。作りに違いがあるとはあまり考えにくい。パケットの取りこぼしも考えたが、Advertisingのときは普通に取れてるから、考えづらいと思う。グル側の作りがあまりよくない、とかもあるかもしれないけど、それならiOSだって同じ現象が起きてよさそうだ。ことは、何か別の理由があるのだろうけど、それっぽい説明が思いつかない。ble2013/12/01[ble]Androidでアプリを動かすとsnifferがうまくいかないわからんシリーズだ。Sniffer(名前はうろ覚え)を使ってパケットキャプチャをしようとしている。Androidの方が慣れているから、Androidにアプリを入れて、SensorTagとの通信をキャプチャしようとしていたのだが、うまくいかない。Advertisingまでは取れるが、connectすると止まる。connectしても続いているが、少しするとホッピングするチャネルがぐちゃぐちゃになって、止まる。だいたいこのどちらかだ。miniと通信した場合は、そんなことはなさそうな感じがする。SensorTagは違いが無いから、OSの差なのか?とはいえ、どちらもアプリとしてはちゃんと動いているのだ。うーん、訳がわからん。これで「PCの性能があまりよくないから」とかだと、嫌だなぁ。Snifferで見ると、こんな感じで出てくる。PDU」なものの中に、ときどきそれ以外のものが出てくる。「L2CAP-S」となっているものが、だいたいデータっぽい。前半のデータは、あんまり気にしなくてよさそうだ。DirectionはSlaveからMasterへ。SensorTagが送ってきているデータだ。0x1Bは、Notificationとして送信された値という意味。0x004Bは、ハンドル。これは、SensorTAgのGATT一覧表[pdf]に載っている。温度=0xf615、気圧=0x8d49、でよいのかな?センサの値をそのまま送ってるだけだろうから、各センサのデータシートを読まないと変換できん。ちなみに、パケットの生データはこんな感じだ。8Eでは、Androidのソースを少し見ておこうかね。ここに一覧があるけど・・・なんでWindows版とかLinux版にわかれてるんだ?あ、インストーラだ・・・。Windows版をダウンロードしたのに、中にはexeとtarが入ってて、tarを解凍するとLinux版のインストーラらしきものが入っていた。Windowsのインストーラを起動すると、勝手にフォルダ掘ってファイルコピーしやがった。Androidのプロジェクトzipだし。インストーラじゃなくていいやん!腹が立ったので、zipとpdfだけコピーしてアンインストールした(pdfはライセンスの説明だけみたい)。Monitorはあきらめ、素直にSnifferアプリを使うことにした。http://processors.wiki.ti.com/index.php/BLE_sniffer_guideSmartTagがiOSアプリと通信している様子を見てみようとしたのだが、何も出てこない。アプリには刻々とデータが表示されているので、通信していないはずはない。SmartTagの横が電源ONみたいなものなのだが、押すと出てくる。モニタを止めて、また再開させると、やはり出てこない。ADV_CONNECT_REQに書いてあるInitAを打ち込んでみたが、それでも出てこない。Channelを38にしてやってみたが、やはりボタンを押す必要があった。ボタンさえ押せば、Channelの設定には関係なくパケットが見えるようである。Configurationはあまり気にしなくてもよさそうだ(いまのところ)。・・・と思ったけど、ときどきボタンを押してもすぐに終わってしまうことがある。うーん、よくわからん。CRCエラーが結構発生しているが、これはスニファが拾いきれなかったとかかな。SensorTagの情報を集めよう集めよう。SensorTagに紙が入ってて、そこにURLが書いてあるんだけど、打ってもつながらない・・・。http://www.tij.co.jp/ww/wireless_connectivity/sensortag/index.shtml?DCMP=advertorial201309&HQS=SensorTag-bs-tech-adv-jpiOSとかAndroidとかのソースがダウンロードできる。AppStoreからインストールしたんだけど、OADファイルでFWアップデートできるってでてきた。Monitorなるものがあるらしい。USBドングルがいるって書いてあるが、今回買ったやつでいいのかな。http://processors.wiki.ti.com/index.php/BLE_Device_Monitor_User_Guideと思ってやってみたが、COMポートで接続するらしい。devicesとして見えている。http://e2e.ti.com/support/low_power_rf/f/538/t/163044.aspxどうも、デフォルトではスニファ用のファームが焼いてあるから、焼き変えろってことらしい。その方法は・・・?CC-Debuggerなるものがいるんか・・・。開発キットで買うとついてきたんだけど、そうしなかったからな。Monitorの方が楽そうなのだが、仕方ない。Monitor用のファームを使いたいかどうかも考えてから買った方がよいでしょうな。SensorTagとCC2540EMK-USBが届いたBLEをRC-S390だけで調べるのは難しいと思ったので、仕様がわかるキットを買うことにした。SensorTagが安いということだったので、それを1つ。あと、BLEのパケットを読むのに使えるというCC2540EMK-USBを1つ。DigiKeyで28日に注文したのに、30日にはもう届いていた!そ、そんなに早いのか??1ヶ月くらいかかるイメージだったので、びっくりだ。上の写真がSensorTagだが、同封の紙に「技適に通ってない」と書かれている。これについては、こちらが詳しい(というよりは、これを読んだので買った)。http://xiangcai.at.webry.info/201311/article_8.html念のため、基板に書いてある番号で検索した。適合した機器の検索サイトに出てきたんだから、大丈夫だ。http://www.tele.soumu.go.jp/giteki/SearchServlet?pageID=jg01_01&PC=007&TC=N&PK=1&FN=349ul&SN=%94%46%8F%D8&LN=6&R1=*****&R2=*****電脳羊さんのサイトで、基板をケースに入れるときに「爪を折らないように」と書いてあるが、やってみて、確かに折りそうになった。透明なふたがあるんだけど、なんか引っかかるようにできていて、かぱっとはいかないのだ。CC2540EMK-USBは、TIの開発キットを買うとそっちにもついてくる。入っていない方を買ったのは、開発キットの方はチップ側のソフトを焼き込まないといかんらしく、それにはIARの開発環境しかない、ということだった。30日までは無料なんだけど、そっから先は買わんといかんらしい。制限無く無料の方はリンクサイズに制限がかかるらしく、それではBLEのライブラリが載らないんだとか。http://vibrosoft.net/archives/56ソフトは、こちらからダウンロード。http://www.ti.com/tool/packet-snifferインストールして、EMKをPCに挿して、アプリ起動。選択ダイアログが出てきた。Startを押すと、取得画面らしきものが開く。三角の再生ボタンっぽいものをクリックすると、おお、なんか取得してるみたいだ。SensorTagの電池を抜いても何か取得してるのであせったが、RC-S390の電源が入っていたようだ。RC-S390のボタンを2秒押しして、LEDが1秒点灯したら電源OFFだ。やって電源を全部落とすと、ログを取得しなくなった。データを見ながらの勉強ができそうだ。HACKSが出たhttp://www.oreilly.co.jp/books/9784873116242/オライリーさんから、NFCの本が出た。HACKSだけだった。HACKSを寄贈いただいたのだ!わーい。「hiro99ma」が初めて活字化された本としてプレミアが出るに違いない(出ません)。私が書いたものは何もないんですけどね。NODOKA)http://www.atelier-nodoka.net/2013/11/oreilly-nfc-hacks/レビュー記事(明日の鍵)http://blog.tomorrowkey.jp/2013-11-27/review-of-nfc-hacks/うちのサイトをNFC観点で見ていくとわかるのかもしれないが、基本的に興味があるのは「作り方」の部分。仕様書から仕様を把握して、それを実装に落とす、というところまでが好きなようだ。そんな私が興味を持ったのは、第2章。Type4とかISO-DEPには注目せざるを得ない。HCEでできるのは、Type1でも2でも3でもなく、4らしいではないか。Type2と3は日本でもよく使われるから解説記事があるけど、Type1と4はあまり例がないためか情報を見たことがない。それが日本語で読めるのは非常にありがたい。Forumからドキュメントは出てるんだけど、知ってる言語で書かれてる方が何かと、ねぇ。DEP/LLCP/SNEPが載っているのも見逃せない。DEPも、LLCPで使うNFC-DEPだけじゃなく、Type4で使う(と思ってるけど)ISO-DEPのことも書かれている。NFC-DEPはISO/IEC-18092に載っていて、それはECMAからダウンロードもできるので無料で情報が得られるけど、ISO-DEPはISO/IEC-14443で、これはまだダウンロードできる仕様書を見つけられていない(あやしいのはあったけど)。APIにはIsoDepもあるので知っておいて損はないんじゃなかろうか。「アプリ作るだけならそこまで知らなくても」というのはあるかもしれないが、技術屋さんとしては訳がわからないものは気持ちがわるいではないか。そこら辺がすっきりできるであろう(個人の感想です)。PC/SCのことも書かれている。4.4が出る前なのでHCEのことは書かれていない。それを待っていたらキクニさんの雨宿りしている人のマンガじゃないけど、いつまで経っても出せなくなるからな。Elementを使わない)。SEは私は操作できないから興味が無いのだけど、仕事でやらんといかん人もおるかもしれん。FeliCaもSIMベースに移行する予定だったと思うので、「Androidで国内端末だから関係ないや」という人もぼちぼち読んでいった方がよいかもしれませんな。Beamなどの基本機能の使い方(=実装の仕方)が書かれている。NFCといえばAndroid端末、って気がするので一番ページ数が多いと思うかもしれないが、実は一番ページが多いのは2章の規格説明だったりする。WindowsはNFPがWindows8から使えるので情報がよく出ているけど、PC/SCは縁遠かった。AndroidでHCEが出てきてType4の振る舞いをする(らしい)となったとき、APDUなるものでアクセスする関係から、PC/SCの方も調べることがあった。うまくはできてないんだけど、この本に例があるので、足がかりに読んでみようと思う。ページ数は少ないが、5章のNFC応用サービスは興味深い。私なんかは自分で作って満足するだけなんだけど、サービスに昇華させろ、といわれたら非常に困る。考慮する点がわからんからだ。この章は「セキュリティに配慮した」というタイトルにもあるように、NFCが持つ情報として考慮すべき事が書かれている。これだけ押さえてれば大丈夫、というのはサービス内容によって変わるため無理だけど、書かれていることと照らし合わせながら、やりたいこととやれること/やらない方がいいことを洗い出していくといいんじゃなかろうか。私は仕事でNFCしてるわけじゃないのだが、2年くらい細々と調べていたのでおおよそのことは知ってるつもりだったけど、いやあ、まだまだですわ。わからないときはこの本を見ればいいや、という使い方ができそうだ。NFCって、それなりに特殊な分野だと思う。通信して、メモリ持ってて、超近距離で、セキュリティも持ってて、とサービスにマッチしなければ使い道がないってくらい特殊だ。「NFC使って何かやろう!」ってよりは「サービスを考えた結果、NFCってのが使えそうだ」というパターンが多いんじゃなかろうか。考えると、NFC技術者って必要になってから生み出されることになりそう。いう人が「仕事でNFCってのをやらんといかんのだけど、何したらいいんだ?」という状況になったときには最適だろう。今のうちにNFC技術者になっておけば、『お客様の中にNFC技術者の方は...』という状況の時に手を挙げられることになる。なるのか・・・?まあ、NFCやろうっていうときに、やったことある人とない人だったら、ある人を選ぶな。いう人になりたいときにも、よいかな。server/client用語が、用語が・・・。似たような感じの言葉がよく出てくるのだが、使い分けがわかっていない。「master/slave」「initiator/responder」「server/client」は、どれも同じような感じがしつつ、やっぱり違うんだろうけど、曖昧なままごまかしてきた。Central/Peripheralまずは、これか。いわゆる「デバイス側」がPeripheralで、その持ち主が「Central」というイメージだ。Central」とある。Profile)の機能ということだろう。Master/SlaveCore_V4.0のp.1639-1640にGAPの4roleが対応する機能一覧がある。