2012年1月31日

[nfc]NFCID (2)

風邪っぽいので、短めの話を選んだ。
「みんなでNFCのお勉強」シリーズ(シリーズ?)。
NFCIDについてだ。

NFCIDというのは、NFCのIDだ。
0, 1, 2, 3とt, iがある。
tとiは、普通付けない。
tは「Target」で、iは「Initiator」だ。
カードエミュレーションやDEPするときのように、どっち側のNFCIDかを区別したいときに付けるだけなので、そんなに気にしなくてよい。
以下、自作の資料に書いていたものを参考に書いているので、間違ってたらすまん。

NFCID0は、NFC-B。
4byte固定。

NFCID1は、NFC-A。SENS_RESの上位2ビットでサイズが決まる。
single : 4byte
double : 7byte
triple : 10byte
4byteのUIDは、ユニークではない。
Mifare 1Kは4byteだったが、Ultralightは7byteだった。
「18092では4byte固定になっている」と当時の私は書いている(Digital Protocol - 4.6.3.2)。
NFCID1 CLnは、カスケードレベル、というものらしい。
名前は聞くが、どういうものかはまだ調べていない。
4byte固定らしい。

NFCID2は、NFC-F。8byte固定。
先頭の2byteでサポートするプロトコルがわかる。
01 FE : NFC-DEPサポート(NFCIP-1)。3~8byteはランダム。
02 FE : Tag Type3サポート。3~8byteはランダム。
03 FE : FeliCa Plug。
それ以外 : Tag Type3サポート。1~8byteはプロプライエタリ(FN管理?)。
なお、システムが複数あるものは、システムごとにNFCID2がある。
共通領域とサイバー領域とか。

NFCID3は、NFC-DEPで使う。10byte固定。
NFC-Fの場合は、10byte中先頭8byteはNFCID2で、残り2byteは0とか。

NFCID1の4byte版はユニークじゃない、となっている。
NFCID2もユニークではない、というのはどこかで読んだのだが、忘れた。
FeliCa Networks社の用語集だったか・・・と思ってサイトを見たら、今日更新されてた。
そして用語集はなくなっていた・・・。
とりあえず、技術情報ページのリンクを載せておく。
SDB-200がある!と思ったが、ツールだけなのね。
まあ、個人で買えるとは思わんが。。

技術情報のページではやはりよくわからなかったので、SONYの技術サイトにある「FeliCa技術方式の各種コードについて」をリンクしよう(English)。

私としても、NFCID2(IDm)でのみのカード識別はやめていただきたい。
怖いからだ。
あくまであれは、PCD(リーダライタ)がPICC(カード)に一時的にアクセスするために取得する
だってねぇ、あれは私でも同じIDmを持つカード機能を作ることができてしまうくらい簡単なものなのだ。
やったことないけど、FeliCa Liteくらいならフルエミュレーションできるんじゃなかろうか。
もしIDmのみで重要な情報(家の鍵代わりとか)を運用しているメーカーなどがあって、鍵が破られてしまうようなことがあると、私のような善人が疑われてしまう可能性があるのだ。
そうなるのは、いやなので、やーやー言っているのだ。
ほら、技術的に可能であったら、技術者としてはやってしまいたくなるではないか。
倫理の問題でもあるのだけど、なるべくなら「そういう状況」が存在しない方がよい。
食欲や睡眠欲と違って、知識欲ってのは何か底が深くて怖いからね。

なんだかんだ言って、長くなってしまった。
私の今回の収穫は、FeliCa Networks社の技術情報サイトだ。
FALP受信をやっていて、サブコマンド一覧にないデータが出てきていたのだ。
まあ、わかったからといってFALP受信ができるようになるわけではないのだけど、知識欲が満たされたので満足だ。

2012年1月29日

[felica]TSN

小ネタだ。

ポーリングコマンドで、TSNが指定できる。
Time Slot Numberだ。

ポーリングコマンドではPOL_RESを送信して、カードからPOL_REQを受信する。
RF領域に複数のカードがあった場合、POL_RESに対して複数のPOL_REQが返ってくる。
もし同じタイミングで返信したり、片方が返信している最中にもう片方が返信すると、無線データが壊れてしまう。

NFC-Fでは(FeliCaでは、なのかも)、POL_REQにTSNを指定し、この値+1のタイムスロットを返信時間として使っていいことにしている。
仕様書では、返信開始までが2.417ms、そこからタイムスロット1つが1.208msと書かれている。
この時間は、212kHz*512と、212kHz*256に相当する。FeliCaの遅い周波数は212kbpsなので、それをタイマにしているのだろう。

タイムスロットの例を見ると、POL_RESがずれて返信されていた。
ということは、これを使えば複数枚の結果を受けとることができるんじゃなかろうか?


そう思って試してみたが、常に同じカードの結果が1つだけ返ってきた。

推測だが、

  • 返信するタイムスロットはランダムではなく、カードで固定になっている
  • InListPassiveTargetは最初に返ってきたPOL_RESの結果を返す

というところじゃないだろうか。

よく見れば、InListPassiveTargetのNbTgは0か1ではないか。
2枚以上ってのはないことになる。
うーむ。

PN533でもそうだったので、市販のR/Wチップでは複数枚に対応する必要がないってことで機能削減されていると考えた方がよさそうだ。
なんとかできると面白いかなー、と思ったのだがね。

[android]AppWidgetを複数扱う

EjectSD、というAndroidのアプリを公開している。
何をするものかというと、SDカードのマウント/アンマウントをするAppWidgetだ。
デスクトップに置く際、マウントポイントを設定してもらい、アイコンをタッチすると、マウント/アンマウント動作をするというものだ。

 

シンプルといえばシンプルなのだが、ここに至るまでは面倒だった。
Acer A500で作っていたのだが、マウント/アンマウントのインテントが飛んでこないのだ。
それより面倒だったのは、SDカードのマウントポイントがよくわからないこと。
getExternalStorageDirectory()で取ってこれる、ということになっているのだが、いろいろとメモリの配置などの関係から、このAPIでは期待するパスが取って来れないことがあるのだ。

そこら辺を適当に処理して、今に至っている。

しかし、最近はSDカードだけでなく、USBメモリもさせることが多い。
要望として「両方なんとかしたい」というものがあった。
まあ、そうだろうねぇ。

一番簡単な対策は、別名にしたアプリをもう1つ公開することだ。
アイコンも別の形にすれば、見分けは付くだろう。
ただこの方法は、あんまり格好がよろしくない。
なんというか「負けた」感じがするのだ。

そんなわけで、土日で複数扱えるように対応していた。


簡単だろうと思っていたのだが、あまり把握していないこともあって、難儀した。

まず、パスの入力。
ListPreferenceを使っているのだが、これはデフォルトのプリファレンスに保存する。
これをAppWidgetごとにしなくてはならない。
考えたあげく、デフォルトのプリファレンスが書き換わったときのListenerで個別に書き写す、というやり方にした。
格好が悪い。。。

 

それ以上に困ったのは、アイコンの更新。
クリックしたアイコンの処理だけしたいのだが、なんか上書きされている。
これは検索するといろいろ情報が出てきた。
出てきたのだが、まねするとインテントが受け取れなくなった。。。

まねしたのは、AppWidgetのIDをURIとしてsetData()する方法だったのだが、インテントフィルタをちゃんと書いてなかったので受け取れなかった(のだろう)。
めんどくさかったので、putExtras()でやるようにした。

 

そして、マウント/アンマウントインテントの受け取り。
mountやumountすると、その結果がインテントでブロードキャストされる。
それをonReceive()で受けとるのだが、そのインテントには当然AppWidgetのID情報など載っていない。
どうしたもんだか・・・と考えたが、もう全部のインスタンスを更新することにした。
AppWidgetManager.getInstance(context).getAppWidgetIds(componentName)としてIDの配列を受け取り、全部に対してupdateAppWidget()してやった。
onUpdate()の中では、IMountService.getVolumeState(path)でマウント状態を取得してアイコンを差し替えている。

 

残るは、過去との互換。
EjectSDはデフォルトのプリファレンス、今回は個別のプリファレンスだ。
うまく切り替えられるように作るべきか・・・と迷ったが、あきらめた。
別のアプリにしてしまった。
パスが1つでいいのなら、前ので十分だしね。


今回、A500がandroid3.2になってからだったが、MOUNTやUNMOUNTのインテントが飛んでくるようになった。
特にインテントフィルタ周りは何もしていないのだが・・・。

2012年1月28日

[rcs620s]RC-S620/S簡易ドキュメントを読む

SONY技術情報サイトにある、RC-S620/S簡易ドキュメント2本。
簡易説明の説明なんか書いても仕方ないかなー、と思ったが、自分のために書いておこう。


RC-S620/S 製品仕様書<簡易版>

p.3

用語について書かれている。
「コントローラ」というのは、リーダライタを制御するパソコンのような意味だ。
シリアルでコマンドを送受信してやらないといけない機器、ということですな。

 

2.ハードウェア仕様

RC-S620/Sの持つ機能や、どうやって接続したらいいかが書かれている。
最初に迷うのは、フラットケーブルが片面なのだけど、どっちに挿せばいいの?だと思う。
間違うと、壊す・・・ことはないが、通信できないので困る。

これは、「2.6 外形寸法」を見るとよい。p.13だ。
左側に、コネクタ側から見た図がある。
破線がコネクタ接点と書かれているので、金属板側に接点があるのだ。

1ピンの位置も確認しておくこと。
私はこの確認が不十分で、1台壊してしまった。

もう1つ注意する点がある。
RC-S620/Sをカードにかざす面は基板がある側だ、ということ。
金属面ではないのだ。
見た目上、金属面にカードをかざしたくなるが、そこは我慢だ。
なんでそうなっているかというと、機器に組み込む際、金属面からネジを打ち込むからだ。
だからおそらく、金属面側は電波が漏れないようにカバーされているんじゃないだろうか。
ともかく、基板側にカードをかざすこと。

「2.3 UART通信仕様」も知っておかないと通信できまい。
なしなしの115200bpsだ。
通信速度を変更したい場合は、RC-S620/Sにボーレート変更のコマンドを送信しなくてはならないのだが、そのコマンドは説明がなかったと思う。
まあ、困らないと思うのでそのままでいいんじゃないかね。

2.4.2に電気的特性がある。
電池で駆動させたいときには、気になるだろう。
もちょっと消費電力が落ちてくれればなー、という気はするが、そういうときにはソフトパワーダウンさせるよりも、電源ごとOFFにして使うときに初期化し直した方がいいだろう。


RC-S620/S コマンドリファレンスマニュアル<簡易版>

p.7

基本ルール。
コントローラから送信したコマンドに対するレスポンスは返すけれども、勝手に送りつけることはないよ、ということ。

p.8

ここから、RC-S620/Sへ送信するフレーム形式が書かれている。
また、RC-S620/Sから送信されるフレーム形式も同じフォーマットだ
ここの「データ部」が、コマンドだったりレスポンスだったりする。

NormalフレームとExtendedフレームがある。
Normalフレームはデータ部が256byteまで、Extendedフレームはデータ部が265byteまで。
私なんかは、たった9byteしか変わらないならNormalだけでいいやん、と思っているのだが、なかなかそうもいかない事情がある。

PreambleとかPostambleとか出てくるが、これは通信パケットでよく使われる言葉だ。
カード側の仕様書にも、同じようにPreambleなどが出てきたと思うが、あれは無線側なので有線側とは関係がない。

p.10

ACKフレーム。
Acknowledgeのことだが、だいたいどこでも「ACK」(あっく)と呼ぶみたいだ。
いろいろな意味があるので、読んで把握すべし。

 

p.11 通信プロトコル

ここから、どうやってフレームをやりとりするのかの説明になる。
エラーが戻る、戻らないなどは、どの層の通信にエラーがあるかで変わってくる。

p.12 データリンクレベル

データリンクレベルでは、p.8から書かれていたフレームのフォーマットが正しければよい。
正しければ、データ部を見ずにACKフレームを返す。
つまり、ACKが返ってこないということは、フレームが間違っているということになる。
自分でコマンドを送信する際は、まずACK返信の有無を確認すること。
ACKを返さないパターンは、p.13に書かれている。

RC-S620/Sは、コマンドを受信してから最大でも3.5msで応答を返す。
コントローラ側でタイムアウトを設定したい場合は、これに通信速度*(コマンド長+ACK長)の時間を加えたものになるであろう。

ACKを返してきてからレスポンスが返ってくるまでの時間は、コマンド依存だ。
すぐ返すものもあれば、何かあるまで返さないものもある。

p.14に、RC-S620/Sのタイムアウト時間が書かれている。
データ部からポストアンブルまでの時間なので、データ部長+2byte。
Normalフレームの場合、データ部は最大256byte。
通信速度が115200bpsの場合、1byteはUART10bitなので86us。258byteなら22.1ms。
よほどたらたらと送信しない限りは大丈夫なはずだ。

p.15 アプリケーションレベル

アプリレベルのコマンドを処理している間に、ホストからACKか異なるコマンドを送信すると、現在実行しているコマンドを中断するので、詳細を確認すべし。
ACKで中断させた場合は、1ms以上待ってから次のコマンドを送信すること。

アプリレベルの場合、シンタックスエラーを返すことがある。
もちろん、データ部が間違っているからである。

 

p.16 モード

今までは通信レベルの話だったが、ここはRC-S620/Sが持つ状態について書かれている。
全部で7つのモードがあるので、意識すべし。
ここでは0と6についてしか書かれていないが、RC-S620/Sを購入後に入手する資料では、他のモードについても書かれている。

このドキュメントは、モード6の「Initiatorモード」のみ書かれている。
Initiatorというのは、カード側にコマンドを送信する方である。
カード側は、Target、と呼ばれる。

 

p.18 コマンド一覧

ここからは、データ部に詰めるコマンドとそのレスポンスについて書かれている。
自分でプログラムを作る場合、送信は「コマンド部を作成するところ」と「データ部からフレームを作成するところ」を作り、受信は「フレームからデータ部を抜き出す」「データ部を解析する」を作ることになるだろう。

このドキュメントでは、4つのコマンドが説明されている。

  • RFConfiguration
  • Reset
  • InListPassiveTarget
  • CommunicateThruEX

最初の2つは、RC-S620/Sの初期化や状態を戻すのに使われる。

InListPassiveTargetは、いわゆる「ポーリング」を行う。
「Passive Target」というのは「受動的なTarget」ということで、普通はカードを指す。
このコマンドを使って、モードを0から6に変化させる。
この動作を「Targetを捕捉する」ということもある(Type-Bは捕捉するタイプではないという話を聞いた)。

CommunicateThruEXは、捕捉したTargetにコマンドを送信するコマンドだ。
例えばFeliCa Liteカードのデータを読みたいなら、InListPassiveTargetでカードを捕捉し、CommunicateThruEXで"Read Without Encryption"を送信することになる。
そうすると、CommunicateThruEXのレスポンスに"Read Without Encryption"のレスポンスが載ってくる。

各コマンドの詳細は、省略する。
FeliCa Developers' BlogのRC-S620/Sサンプルのソースを読むと、どういう順番でコマンドを使えばよいか、コマンドの作り方、フレームの作り方など、基本的な部分はわかる。

Resetは、レスポンスが返ってきた時点でリセットされるのではなく、その次にコントローラからのACKを受信したときに行われるので、注意しよう。

InListPassiveTargetは「結局Initiator Data部に何を書けばいいのよ」と思われそうだ。
私の認識では、BrTyによって無線送信速度とTargetを決め、Targetの種類によってInitiator部をどう使うかR/Wが決めてうまいこと無線コマンドを送信している。
例えばFeliCaの場合、POL_REQという無線コマンドを送信するのだが、そのパケットをInitiatorDataに書いてやる。

[0] 0x00 (POL_REQコマンド)
[1] SystemCodeの上位
[2] SystemCodeの下位
[3] Request Code
[4] TimeSlot

とりあえず実行するなら「0x00 0xFF 0xFF 0x00 0x00」でよい。
詳細は、FeliCa LiteやFeliCa Standardのユーザーズマニュアルにある「Pollingコマンド」の説明を読むとよい。

もちろん、InListPassiveTargetでType-AやType-Bも見つけることができるので、興味がある方は探してみるとよいだろう。

CommunicateThruEXは、ちょっと特殊なコマンドだ。
R/Wに送るコマンドの中に、Targetへ送るコマンドを含める。
そのため、Target側のタイムアウトも考慮しなくてはならず、パラメータにTimeoutがある。
FeliCa Developers' Blogのサンプルでは、FeliCa携帯電話にURLをPUSHするようになっているが、PUSHするデータは携帯電話(=Target)に送信するため、CommunicateThruEXを使っている。
このコマンドは、Targetへのデータ(DataOut)に255byteまで載せることができる。そのときのコマンド長は259byte。256byteを超えてしまうので、Extendedフレームが必要になるのだ。


ざーっと流して読んでいったが、なんとなくわかっただろうか。

R/Wのドキュメントはだいたいこんな作りになっているので、見慣れるとPN533のドキュメントなども読むことができる。
慣れておくとよいだろう。

touchanote

Gigazineに、TouchanoteというNFCサービス(と呼んでよいのかな?)の記事があった。

http://gigazine.net/news/20120127-nfc-evernote-touchanote/

勢いで、10枚買った。
それでも800円以内だ。

何も考えずに買ったけれども、おそらくType-Aだろう。
Type-Aなら、MifareのUltralightかなぁ。

 

まあ、私はAndroidとかは持ってないんだけどね。

ざっと考えつくのは、引っ越し荷物を自分で梱包したときだ。
どの箱に何が入っていたのか・・・。

 

ねむすぎるので、ねます。

[rw]リーダライタRC-S620/Sへアクセス

私はNFCリーダライタとして、SONYのRC-S370とRC-S620/Sを持っている。

RC-S370は、USB接続である。
そのため、通信するにはドライバが必要になる。

RC-S620/Sは、組み込み用なのでケーブルなどは特殊ではあるが、シリアル接続である。
よって、シリアルをうまく扱いさえすれば、ドライバを書かずにアクセスできる。

SONYのリーダライタだけでなく、他のリーダライタも似たような感じだと思う。
通信の方法と、通信データがわかれば、どうにかして使うことができる。


私は、RC-S620/SにCP2102を接続して、パソコンとつなげている。
シリアルになれば、プログラムを書くのが比較的楽になる。

いや、動作を見たいだけであれば、プログラムを書く必要もない。
RC-S620/Sのプロトコルをバイナリファイルで作成して、TeraTermなどで送信するだけでいいのだ。
プロトコルが正しければ、リーダライタは応答を返してくれる。
正しくなければ、おそらく無応答だ。
無応答なのは、セキュリティのためだろうね。


と、この流れでプロトコルの話までしたいところだが、そうはいかない。
RC-S620/Sのドキュメントには、プロトコルのことは載っていないのだ。
簡易マニュアルにはいくつか書かれているが、それを説明してもしかたあるまい。

この1年で、NFCドライバをいくつか見てきたので、書かれていないプロトコルもいくつかわかっている。
が、そういうものを記事に書くのは、ちょっと気が引けるのだ。
PN533ならプロトコルのドキュメントが入手できるならいいけど、PaSoRiなどは入手できないからだ(私も持ってないよ)。

入手できないからこそ説明するんじゃないか!と言われそうだが、曖昧な情報を流すのもいやなものなのだ。
それに、著作権とかいろいろと関係しそうな気がするので、及び腰になってしまう。

まあ、私も1年くらいかけてずいぶんとわかった気がするので、興味がある方も1年くらい眺めていれば、習わぬ経を読む、ではないけど身についてくると思う。

2012年1月27日

[nfc]NFC開発をするときに安くやりたい(ドキュメント編 - 3)

FeliCa

PaSoRiやRC-S620/S、FeliCa Liteを使うのであれば、FeliCaの技術情報を見ておいた方がよい。
http://www.sony.co.jp/Products/felica/business/tech-support/index.html
PaSoRiで使われているR/Wのコマンド仕様はあまり出ていないのだが、ここにある「RC-S620/Sコマンドリファレンスマニュアル」がもっとも有用であろう。
最近は情報がいろいろと出てきているので、今後に期待である。
RC-S620/Sを購入するとドキュメントを請求できるので、やっておいた方がよい。
RC-S956のコマンドについては有償になるため入手できないが、ピン配置やコマンド一覧くらいは載っているのだ。
また、DoCoMoやSBMの技術情報も面白いかもしれない。
「おサイフケータイ」という言葉についても知っておくとよいかも。


NXP

Androidに搭載されているPN544などで有名な、NXP。
もちろんNFCだけでなく、半導体全般をやっている。
巨大だ。
そして、公開されている情報も多い。
型番がわかれば、ネットで検索すれば出てくるくらいである。
PaSoRiやRC-S620/SなどのRC-S956系チップが搭載されたR/Wを使う場合、同じICバージョンのPN533を参考にするとよいだろう。
http://www.nxp.com/documents/user_manual/157830_PN533_um080103.pdf
もちろん、異なるコマンドもあるが、参考になる。
コマンドが異なるかどうかは、やってみるのが一番簡単だ。

いろいろとリンクを載せたかったのだが、メインで見ているのは上記2社だった。
あとは、随時検索している。
「NFCの情報」とひとことで言っても、種類がいろいろある。
私が主に知りたいのは、NFCカード(PICC)やR/W(PCD)の制御方法だ。
SDK for NFC Starter KitやAndroid APIのように、アクセスできるようにしたライブラリの情報を知りたい人もいる。
NFCカードに書き込まれたデータ(NDEFなど)に興味を持つ人もいる。
そしてそれらを使ったサービスに興味がある人もいる。
私が検索した感じでは、サービス関係の結果が多かったように思う。
まあ、お金などに関係するから、興味を持つ人が多いのだろう。
Androidに搭載されるようになったことで、開発側の人も興味を持つ人が増え、それにつれて情報がたくさん出てくるようになった。
私にとっては、それが一番嬉しい。
そしてだんだんと、自分でNFCアプリを作ってサービスも提供するような人が出てきた。
あまりサービスに興味を持っていない私であるが、「安くやりたい」の効果が一番大きいのはサービスの開発だと思う。
サーバは安く構築できる時代になったし、携帯電話に搭載されて敷居が下がり、環境はかなり整ってきた。
「カードをかざす」という行為自体も、敷居が下がったと思う。
次は我々の番だ、ということかもしれませんな。

FeliCa LiteとNFC-F

FeliCa Liteという、FeliCaのカードがある。
FeliCaのカードの一種というよりも、FeliCa Liteというカードと認識した方がよい。

 

NFC Forumのドキュメント「NFCForum-TS-Type3-Tag_1.1」によると、NFC-FのType3タグで使用できるコマンドは3つである。

  • Polling
  • Check
  • Update

FeliCa Liteユーザーズマニュアルでは、こうなっている。

  • Polling
  • Read Without Encryption
  • Write Without Encryption

名前は違うが、同じ機能だ。


FeliCa Liteカードは、そのままでは「FeliCa Lite」だ。
これを「NFC-F」にするには、MCブロックを書き換えなくてはならない。

簡単なのは、ツールを使うことである。
http://www.sony.co.jp/Products/felica/business/products/tagreader.html

また、カードを使うときの捕捉方法も気にしなくてはならない。
日本語版の資料が見つからなかった・・・。
http://www.sony.net/Products/felica/business/tech-support/index.html#NFC01

2012年1月26日

[nfc]カードを手に入れる

リーダライタを買い、パソコンでアクセスできるようにしたとしよう。

次にほしいのは、読み取るカードであろう。
最近の人であれば、NFCチップが入った携帯電話を持っているかもしれない。

しかし、何台も持っているわけじゃなかろうし、パッシブなカードがあっても困るものではなかろう。


日本であれば、とりあえずSuicaみたいな交通カードが手軽だろう。
入手しやすいし、乗り物に乗ることもできる。
私はnimocaを持っている。nimocaはいいぞー。

いいのだが、セキュリティが厳しいので、あまり自由に扱えない。
書き込みもやりたいなら、別のカードがあった方がよい。

 

会社によっては、社員証がNFCカードということもあろう。
私は2つ社員証があるが、どちらもNFCだ。
しかし、社員証に間違って書き込んで壊してしまうと、弁償ものだろう。
「安くやりたい」のであれば、そういった危険は排除すべきだ。

 

となると、自由に使えるカードを購入する、という手段が残る。
お金はかけたくないのだが、仕方あるまい。

私は、スイッチサイエンス社から購入した。

http://www.switch-science.com/products/list.php?category_id=52

けちくさいので、FeliCa Liteカードを2枚だけ買っている。
もっと買えばよかったような気もするが、たくさんあっても仕方ないといえば仕方ない。

FeliCa LiteはNFC-Fカードにもなれるが、他のTechnologyも試したかろう。
それなら、Mifareだろうか。taspoもあるかもしれんが、私はタバコを吸わんのでわからん。
私はMifare 1Kを10枚と、Mifare Ultralightを1枚買った。
Amazon・・・だったと思う。
orange tagsさんだ。

Type-Bのカードは、住基カードとかIC免許証くらいしか思いつかない。
海外ではかなり使われているようなのだがね。
BはAやFとはしくみが違うらしいので、まだ動かしたことがない。

 

携帯電話に搭載されているならば、それはなかなか役に立つ。
私の場合はP906iという携帯電話を持っているのだが、PaSoRiから無線が出てるかどうかの確認に使うことができる。
無線の領域に入ると、LEDが点灯するからだ。
いやいや、携帯電話は便利なものだ。

PaSoRiも、旧タイプは搬送波を出すとき(検出?)にLEDが点灯したものだが、今はコストダウンのために黒PaSoRiになってしまった。
惜しい。


数回にわたって「安くやるには」と目標としてやってきたのだが、カードについてはいいアイデアが浮かばなかった。

FeliCaのハッカソンなんかにいくともらえた、という話を聞いたこともあるので、開発の勉強になるしカードももらえるし、で行ってみるといいのかも。

ACR-122UというR/W (2)

APDUについて書こうと思ったが、今日は読む時間が取れなかった。

ACR-122Uの送受信データを見せてもらった。
PN533系のコマンドに似ているが、PN533には0x60というコマンドはない。
話によると、ACR-122UはPN532が搭載されているということであった。
PN532のドキュメントを見ると、0x60はInAutoPollというコマンドで、引数で指定したターゲットをポーリングするコマンドのようだった。
ほほう。

PN533やRC-S956(PaSoRi)とPN532は、コマンドが多少異なる。
PN533とRC-S956は、GetFirmwareVersionで取得するとわかるが、同じようなバージョンである。
PaSoRiやRC-S620/Sを使いたい人は、PN533のドキュメントを見ると良かろうというのは、そういうことなのである。

 

昨日気にしていたPseudo APDUだが、タグやR/Wに対して直接コマンドを送信するために使うようである。
4byteの識別子のようなもの "FF 00 00 00"と、送信するデータ長、そしてデータで構成される。
libnfcのACSドライバは、このモード(Direct Transmit)しか使っていない。

 

今日は読まないが、PC/SC Workgroupのドキュメントがあったので、リンクだけ置いておく。
http://www.pcscworkgroup.com/specifications/specdownload.php


日本語でしか書いていないブログだが、英語圏の人に読んでもらってるとは思っていなかった。
ありがたいものである。

日本語なら自由に書けるのだが、英語の読み書きは非常に苦手としている。
応答がおかしかったとしても、気にしないでください。