インベントリのパラメータを試す１

UHF帯のRFIDタグを読み取りする場合、リーダでインベントリというのを行います。インベントリを行うと、たくさんタグがあってもアンチコリジョンとかうまくやってくれて、こんなタグがあったよーというのを通知してくれます。そのインベントリですが、動作を設定するパラメータがわんさかあります。
今回はその中で Session というのを試してみます。

Gen2のタグには、インベントリ済みフラグというのが内蔵されています。リーダの読み取り範囲にたくさんタグがある場合、すべてのタグが同じように返答していたらこれはなかなかすべてを聞き分けるのは難しいです。そこで、自分はもうインベントリされたよというフラグをタグが持っていて、インベントリ済みの場合はもう黙っておくということになっています。そうすることでインベントリが済んでいないタグだけが返答するようになります。

で、このフラグなんですが、インベントリされたらフラグを ON にするんですが、こんどは OFF にするタイミングはどうするのさ？という問題が出てきます。リーダから「ほうらお前らインベントリフラグを OFF にするんだ」的なコマンドを出すのが１つのやり方です。それだけだとずっと ON の状態のままのタグも出てきてしまいますので、一定時間過ぎたら OFF にするという仕組みにもなっています。で、一定時間って何よ。どんだけよ。という話になるんですが、これが Session の設定になります。

SessionにはS0、S1、S2、S3と４種類あって、S0は速攻で OFF にします。正確にはリーダからの電波が途切れてチップへの給電が無くなったら OFF になります。S1は 500msくらい ON の状態を保持します。S2とS3は違いがよくわからないんですが、どちらも５秒ほど ON の状態を保持します。

S0だと、すぐにフラグがリセットされるのでタグがやいのやいの反応し、タグがたくさんある場合に混線が生じます。S2とかにすると急におとなしくなって、短時間に何度も読み取りしようとすると反応しない場合があるわけです。

試してみましょう。いつものMorphicです。

設定の右下に「Session」がありますねー。
まずは０でタグの読み取りをします。
タグは適当に１５個ほど置きました。

読み取りを開始するとピーピーピーピーひっきりなしに音がしています。
しばらく読み取ってから統計を見てみると、

平均して５３個／秒で読み取りしたようです。
では Session を３にしてもう一回読み取ります。
今度は何回かピーといった後、全然音がしなくなりました。読み取ってない（タグが黙ってる）ようです。
しばらく読み取ってから統計を見てみると、

平均で２個／秒になってしまいました。
というわけで Session の効果はかなり違いが出るようです。
大量にタグがあって、１回読めばもういいや―的な場合は３、タグは少量で高速で読み取りたい場合は０に設定するのがいいようです。

NTAG210のUIDミラーを試してみる

NTAGの新しいシリーズにNTAG210とNTAG212がありますが今回NTAG210を入手しましたので早速試してみました。新シリーズでは新しくUIDミラーという機能が搭載されています。タグのUIDをNDEFメッセージの任意の場所にミラーできるという機能です。

NTAG210とNTAG212ですが仕様書を見るとサイズの違いだけのようです。NTAG210は80byte、NTAG212は164byteです。自由に書込みできる容量だけみると、NTAG210はMifareUltralightと同じ48byte、NTAG212はNTAG203より少し少ない128byteになっています。

こちらがNTAG210のBullsEyeです。

中身を見てみます。

Page3の１バイト目が 0xE1 になってますのでNDEFフォーマットされています。データは 0x03 0x00 0xFE で空のNDEFが確かに入っていますね。
まずここにタグのUIDをパラメータとするURLを書きます。

書きました。UIDの部分は 00 00 00 00 00 00 00 にしています。
ここでタグに細工をするとこのUIDの部分にタグ自身のUIDがコピーされるようになります。
正確には上書きされるのではなくて、タグ読み込み時に置き換えられるようです。
細工はNTAG210の場合Page16に行います。Page16の構造は仕様書によりますと、

　　Page 16   MIRROR_BYTE  RFUI  MIRROR_PAGE  AUTH0

となっています。MIRROR_BYTEとMIRROR_PAGEで、何ページの何バイト目にミラーするかを指定します。ですので、UIDをミラーしたい開始のページ（４～１５）とバイト（０～３）を書き込むわけです。
MIRROR_PAGEには開始ページをそのまま書けばいいですが、MIRROR_BYTEの方は特殊で上位３ビット目と４ビット目の２ビットを使って０～３を指定するようです。

ではやってみましょう。先ほど書き込んだタグのデータを見てみると、

Page10の２バイト目から 0x30 (ASCIIで数字の０）が続いているので、ここにミラーすればいいようです。というわけで MIRROR_PAGE には 0x0A（Page10）、MIRROR_BYTE には２進数で 0001 0000（１６進数で 0x10）を書込みます。
書き込んだあと、もう一度NDEF読み込みをしてみると、

ちゃんとUIDのところにタグのUIDが表示されています！便利ですねー。

ネットと連携させる場合、ほとんどの場合タグのUIDをパラメータとするURLを使用します。そうするとタグごとにエンコードする内容が異なることになります。しかしこの機能を利用すればエンコードする内容はすべてのタグで同じにできるわけですね。なるほど。

Galaxy Nexusの謎

NFCには３つのモード（リーダ／ライタモード・P2Pモード・カードエミュレーションモード）がありますが、カードエミュレーションモードが使用できる端末はあまりなくて、Galaxy Nexusもカードエミュレーションには対応していません。しかしカードエミュレーションに対応してないからといってUIDが無いわけでもありません。
MANICA EXCEL TOOLとACR122リーダを使用してGalaxy NexusをACRリーダにのせてみると、

ほら、IDが入ってきます。ですがACR122の方は激しくピコピコピーピーしています。そのままにしておくと、

あら、どんどん別のIDが入ってきます。何なんでしょうか、これは。

NFCIP-1という通信規格を見てみると、この答えがあるようです。
NFCIP-1ではNFCIDというものが出てきます。これは複数のタグが通信範囲に存在する場合、１枚をどのように特定するかといういわゆるアンチコリジョンを実現するためのIDになります。

で、このNFCIDですが、規格では基本的にランダムということになっています。
同じ通信範囲の特定の１つを選択できればよいわけですから、ランダムでもＯＫなんですね。
ただ、NTAGやFeliCaなどのチップの場合は独自に設定された自分のUID(IDm)をNFCIDとしているわけです。

具体的にどんな感じなんでしょうか。
NFCIDにはNFCID1、NFCID2、NFCID3の３つ（※NFCIP-1の場合）があるようです。

NFCID1
106kbpsの通信速度で、カスケードレベルというのがあって、レベル１の場合は4byte、レベル２は7byte、レベル３は10byteのNFCIDになります。4byte、7byteということで何となくわかるかと思いますがMIFAREですね。NFC-A相当ということになります。また、レベル１の場合で先頭が 0x08 の場合は残り３バイトはランダムという規定になっているようです。

NFCID2
212kbps、424kbpsの通信速度で、8byteのNFCIDになります。こちらはNFC-F相当です。FeliCaですね。先頭が 0x01 0xFE の場合は残り６バイトはランダムということになっているようです。

NFCID3
P2Pを行う場合に使用される10byteのNFCIDのようです。

では先ほどGalaxy Nexusから取得したUIDを見てみましょう。8byteですね。ということはNFCID2が来てるってことですかね。先頭が確かにすべて 0x01 0xFE になってますので後ろの６バイトはランダムって事なんですね！

なるほどー。UIDは固定って思っちゃってるんで違うIDがバラバラ飛んでくるとウッ？ってなっちゃいますよね。

でもちょっと待ってください。NFCID2がGalaxy Nexusから飛んで来てる？NFCID2？NFCID2ってNFC-Fじゃね？
え？何で？なかよしなの？複雑ですねー。　謎です。