2011/02/27

[nfc][dep]PFB

まだISO 18092を眺めている。
ようやく、DEPの章に入った。

前回、DIDとNADはPN533が自動でやってくれている、と書いた。
しかしDEPの場合は、アプリ側がやってやらなくてはならないようだ。

InDataExchange()は、パラメータをそのまま送るだけである。
受けとる方も、そのまま受けとるだけである。
このパラメータの中身が、プロトコルによって変わってくる。
私が見ているのはISO 18092のDEPで、おそらくNFC-DEPと同じ物だ。
しかし、ISO 14443にもDEPがあり、それはそれで別の物だろう。
どっちにしても、送るコマンドはInDataExchange()で済む、ということになる。


さて、ISO 18092のDEPでは、パケットの頭にPFBというデータがつく。
「Information」「ACK/NACK」「Supervisory」のどれかとなる。
そして、それらの使い方も書いてある。

基本ルールは3つ。

  • Initiatorから始める。
  • More Informationを受信したら、ACKを返す。
  • Supervisoryはペアで使う。REQとRES。

Initiatorルール

  • 不正なパケットだったら、NACKを返す。
  • NACK未送信でタイムアウトしたら、attentionコマンドを送信する。
  • NACK送信済みでタイムアウトしたら、NACKを再送する。
  • ACKを受信したら、データの続きを送信する。
  • DSL_REQに対するDSL_RESがなかったら、DSL_REQを再送するかターゲットを無視する。

Targetルール

  • Targetはdata pduの代わりにRTO pduを送信できる
  • chainingを含まないパケットを受信したら、データだと認識する。
  • NAKを受信したら、再送する。
  • 不正なパケットを受信したら、返事はせずにそのまま待つ。
  • Supervisoryのattentionコマンドを受信したら、attension応答を返す。

いくつか、新しく用語が出てきた。

chaningは、連続しているデータのこと。
1回に254byteくらいまでしか送信できないので、何度かに分けてデータを小分けにして送ることになる。
その小分けした部分を送るとき「まだ続いてますよー」という意味を持つ。
それがPFBの「Multiple Information」なのだけど、ここで「More Information」と書いてあるのが気になる。
同じものと思いたいのだが、それなら同じ用語を使ってほしい。。。

そしてRTO。
これはいきなり出てきた上に、説明がない。
どうやらこれは、ネットワークの用語みたいだ。
Receive Time Out。受信タイムアウト。
Supervisoryにtimeoutビットがあるのだが、それを指しているのだろう。
Targetにのみ、Response timeout extensionというデータが載っていた。


さて、R/Wから見ると、この仕様はかなりシンプルである。
無線上はあれこれとパケットの種別が違うのだけど、有線コマンドとしてはそんなに種類がないからだ。

LLCPは、この上に載っかることになる。
ISO 14443であっても、同じことだ。
しかし・・・LLCPの上には何を載せたらいいんだろう?
OSI参照モデルでは、ネットワーク層が来る。
TCP/IP参照モデルでは、インターネット層にあたるらしい。IP、の部分。
たぶん最後はAndroidに載せるつもりなのだろうが、どうしたものか。。。

[nfc]DIDとNAD

ISO 18092を眺めている。

DEPでやりとりするとき、DIDとかNADとかいう用語がしばしば出てくる。

  • DID : Device ID
  • NAD : Node Address

InJumpForDEPの戻り値には出てくるのだが、TgInitAsTargetに出てこない。
なんだかわからなくなってきたので、ISO 18092をひもといているところ。


これは、属性要求であるATR_REQに出てくる。
何をするにしても、まずATR_REQ/ATR_RESのやりとりから始まると考えてよかろう。
(FeliCaの場合は、POL_REQ/RESのあとでATR_REQをやりとりする。)

シーケンスからすると、InJumpForDEPでInitiatorが送信して、TgInitAsTargetで受けとっている。
ってことはInJumpForDEPのパラメータにありそうなのだけど、ない。

どうなっているかというと、これはPN533が自動でやってくれているからのようだ。
使うかどうかは事前に設定しておくのだが、それにSetParameters()を使用する。
デフォルトはどちらも未使用なのだが、RC-S620/Sも同じかなあ。


他にも気になっていたパラメータがあるので、書いておこう。

  • BS, BR : 送信・受信のビットレート。847kbps以上が使えるなら、それぞれのビットを立てる
  • LR : PPのbit5-4。有効なデータ長。64byte, 128byte, 192byte, 256byteの4種類から選ぶ。

これらは、アプリ側が対処せんといかんのかな?
いかんのだろう。。

NFC Protocolでは、BSi, BRiは0000で、BSt, BRtは無視しろ、とある。
LRは、サイズが64byte, 128byte, 192byte, 254byteになっている。
なぜ微妙に異なるのだ・・・。

2011/02/26

[nfc]まだこだわるActive/Passive

もうやめよう、もうやめようと思いつつ、なかなか終わらぬ、この不思議な感情(おもい)...

と、意味もなく短歌調で始めてみた。


さっき、朝方印刷したISO 18092のドキュメントを見てみた。
書いてあることは、今までと同じだ。
しかしここまでずっと同じような文章を見ていると、気になることがあった。

Passiveの場合、相手からの搬送波に自分のデータを載せてくる。
Activeの場合、自分から搬送波を出して電波を出せる。

よく考えると、携帯電話に載せた場合、チップ自身はかなりの電力を使うため、相手の搬送波くらいでは起動できない。
どうしても、自前の電源が必要だ。
もしかすると、単にそれだけのことを指しているのか?
つまり「カードに搭載しているチップはPassiveで通信できるけど、電源が必要となるチップはActiveでしか通信できんよ」、と。

でも、もしかするとさらに上を行っていて、チップを載せている携帯電話のような端末でも、Passiveで動くのかもしれん。
私の予想など、たかが知れているからな、ふっ。。。

[2.3.3-r1]パッチを当ててみたが、なかなかビルドできん

いやあ、久しぶりにAndroidを触っている。
NFCをやっているせいでもあるが、それよりも64bitでやるようになったのが大きい。
VMwareでは動かないのよねぇ。
動かせないことはないかもしれんが、わざわざ環境を作るのが面倒くさい。




それはともかく、なんとか2.3_r1に2.3.3_r1のパッチをあてようと苦労している。
苦労しているが、なかなかうまくいかん。
どうやったかというと、repoでandroid-2.3.3_r1をとってきて、それとandroid-2.3_r1の差分を取り、git diffを使って差分を取り、patch -p1でパッチを当てていったのだ。
手動でやろうとして前回諦めたのだが、今回はperlで何か作ってみた。
こんなのだ。

(あとではりつける)


自分で修正していたファイルにパッチが当たらないのは、まあわかる。
でも、なんか他のもうまくいってない。
これは、スクリプトの作り方が悪いのか、考え方が間違っているのか。。。

[nfc]RC-S620/S用のクラスを作ろう

解説コーナーではありません。。。
自分で「やろう」という気持ちを沸き立たせるためのものです。


今、自分のところでは、SONYさんのArduino向けライブラリを使っている。
ダウンロードするときに「改変する権利がある」と書いてあったので、Android向けに変更して公開してもいいんだろうなー、と思っていたが、それは別の話ということを教えてもらった。
公開しなくてよかった。。。

とはいえ、そこが公開できないということは、全体的に公開できないのと同じだ。
いや、そもそも公開していいんだかどうだか・・・。

そんなこんな思っていたら、最近のInterface誌には、RC-S620/Sの記事が載っていた。
RC-S620/Sへのパケット構成や、初期化コマンド、ポーリングコマンドまで出ている!
パケットの構成と、初期化の仕方が公開できるのであれば、あとはPN533のドキュメントを見ながらやっているので、RC-S620/Sの仕様書入手条件である「仕様書に書いてあることはネットとかに書いたらいかんよ」という制約から逃れることができる。

できる・・・よな?
まあ、当たり障りのないところでやってみよう。
怒られたら、そこは消そう。

基本的に、RC-S620/Sを買ったけどどうしよう、という人向け、くらいのもので。


まず、RC-S620/Sの「/S」は、シリアルのSだ。
だから、通信にはシリアルポートが必要となる。

なので、書き込みと読み込みのAPIを作ろう。
これは公開しなくてもよいだろう。
内部で使う以外のことは、まずない。

Linuxで普通に開くとブロックするから、NONブロック対応しておいた方がよかろう。
このNONブロック対応は、キャンセルできるようにするための意味が強い。
たぶん、たぶんだが、通常でアクセスしてデータ待ちになったとしても、そのコンテキストが止まるだけで、OSとしては問題なかろうと思うのだ。
マルチスレッドが使えるシステムなら、何もしなくていいかも。

でもまあ、世の中そんなにいいシステムばかりでもないから、コールバックできるようにもしておいた方がいいんだろうなぁ。


パケットのことは、いろいろなサイトに書かれているので、いまさらここで書くことはあるまい。
RC-S620/SへのパケットのことはInterface誌に書かれているし、カードへのパケットについてはISOなどに書かれている。

初めての方は、まずはパケットフォーマットに従ってRC-S620/Sへ書き込んでみてほしい。
反応があるか、エラーが返るか、反応がないか。
そのどれかであろう。

配線さえ間違えていなければ、恐れることはないのだ!

2011/02/25

android2.3.3_r1が出ている

今朝、Android Platformの2.3.3_r1が出ていた。

NFC関係のところだけ落としてみてみたが・・・うーむ。
何をうなっているかというと、RC-S620/Sの対応をどうしようか迷っていたからだ。

できれば、APIもそろっているし、使えるAPIで構成されたアプリであれば動くようになるから対応させたいのだが・・・。
だが、気力がないし、できそうな気がしない。
自分がAndroid携帯電話を買うような気がしないので、ここでがんばってもなー、という気持ちがかなりしている。

なので、ここは自分に無理をしてAPI対応させようとするよりも、自前のAPIで動く物を作ることに邁進しよう。
今のところ、SONYさんから出ているArduino用ライブラリを改造した物を使っているけれども、今月のInterface誌にはRFConfigurationのパラメータ説明があったので、自前で作成できそうだ。

では、今週末は自前ライブラリへの置き換え作業にしよう。
といっても、オリジナルの部分はほとんど残ってないな・・・。

2011/02/24

[nfc][dep]Active時はRF止める

調べるつもりはなかったが、見てしまった。

InitiatorがActive Modeを投げる場合、投げた後でRFを止めるらしい。
つまりこれが「あんたが(も?)Activeになるんだよ」という意思表示なのだろう。
RFが止まるから、受け取ったTargetもRFを出せるようになるのだ。
止めていないと、RFCAして、何もしないのだ。

まあ、それくらい知っておけばいいのかな。
もう力尽きて、文章が頭に浮かんできません。

2011/02/23

[nfc][dep]InJumpでなくてもよい?

PN533の無線部シーケンスだけ見ていると、DEPするのにInJumpForDEPを使わずとも、ポーリングで使うInListPassiveTargetでいいんじゃないの、という気がした。

InListだと、対象は必ずPassiveに限定されてしまう。
が、それで困ることはないと思う。
DEPを自然な感じで行うとすれば、データを送る方がイニシエータ、データをもらう方がターゲットになるだろう。
そして「データくれー」と思ってる人は先に待ち受け状態にして・・・ってのはないのか。
イニシエータからの搬送波を検出して、Pushを受けるなり、ターゲットになるなり、カードとして振る舞うなりあるだろう。

まあ、実証が必要だろうが、気が向かないとやらんな。
今はまだ、その前段階だ。
知識が足りないので、どう実装していくか検討せんとね。

[nfc]能動と受動、もう一度

まだ続いている、このネタ。
いい加減終わらせたいのだが、自分が納得するまではやらんと。

前々回はNFC、前回はISO 18092。
そして今回は、PN533のドキュメントで見ていこう。


まず、整理しよう。

「Active」という考え方が出てくるのは、P2Pのときだけのはず。
ターゲットがカードであれば、自分でRFを作ることができないからだ。
「俺のデータを読め」というカードはなく、もしそういうことをやるならDEPになる、と思う。

そうすると、自分でRFを出せる=イニシエータ、になってしまう。
しかしP2Pは、イニシエータとターゲット間のHalf-duplexだ。
イニシエータとイニシエータのP2Pは、ないはず。

ということは、起動時にイニシエータ、ターゲットでそれぞれ起動し、イニシエータがターゲットに「お前がActiveになれよ」と命令するしかないのではなかろうか。
その線でドキュメントを見ていこう。


PN533によると、ホストから見るとActiveもPassiveも使うコマンドは同じとのこと。
RC-S620/Sはわからんが、同じ動きをすると考えておこう。

では、InJumpForDEPのパラメータにあるPassive/Activeは何を意味しているのだ?
このコマンド自体、自分がイニシエータであることを認めている。
イニシエータがDEPとして初めて使うコマンドが、これなのだ。

p.82から説明が載っていた。

ACTIVE MODE

  • Activeと通信速度を設定
  • ATR_REQにNFCID3iとGiを載せて送信。
  • ATR_RESの受信。NFCID3tと属性Tgを覚える。
  • ATR_RESの中身はホストにも渡す

PASSIVE MODE

こっちは、106kbpsと212/424kbpsで違うみたい。

if(106kbps) {

  • ターゲットを1つ選ぶ(SENS_REQ, SDD_REQ, SEL_REQ)
  • 後で使うためにNFCID1tを保存
  • ATR_REQにNFCID3iとGiを載せて送信。

} else if(212kbps || 424kbps || 847kbps) {

  • SDDを処理?
  • POL_REQにPassiveInitiatorDataを載せて送信。
  • ATR_REQにNFCID3iとGiを載せて送信。

}

  • ATR_RES受信に成功した場合、そのターゲットはTPEだ。
    NFCID3tと属性Tgを覚える。

※どっちのmodeにせよ、ターゲットをアクティベートする前にホストでコマンドを中断したら、RFもOFFになる。


「RF出せ」みたいなのは見当たらなかったな。
シーケンスだけ見ると、Activeの方が少なくて済むし、Passiveは普通のカードみたいにポーリングしてから始める、みたいなところしか違いがわからなかった。
このあたりは、18092にも同じようなことが書かれていたように思う(あんまり読んでないけど)。

いろいろとドキュメントを眺めてきたが、ActiveだのPassiveだのは、取り決めの問題だと思った。
「送信側はPassiveにしてね」とか、その程度。
実装する方からすると、Activeに対応するのは面倒だから、Passiveだけがいいなどとなるのかな。
だって、Passiveならカードとも同じなはずだし。

さて、そこがどうあるべきかは、LLCPドキュメントにはなかったと思う。
ということは、Digital ProtocolかActivityか。。。

Activityドキュメントはあんがい重要であることを昨日知ったばかりだ。
読まねば・・・。

2011/02/22

[nfc]能動と受動、再び

何となく曖昧にしてきたが、DEPをやりはじめると気になって仕方がない。
PN533のシーケンスを見ると、能動でも受動でも、ほとんど一緒なのだ。
いったい、何が違うのだろう?


幸いなことに、ネットでISO 18092のPDFが手に入った。
これにはちと驚いた。
JIS X5211でもいいんだけど、なんか使いづらい。
PDFは英語なんだけど、NFCのドキュメントも英語だし、まあいいや。

Passive Communication Mode

イニシエータが、ターゲットに対してRFを供給する(電源用など)。
ターゲットは、供給されている間は動作する。

Active Communication Mode

イニシエータとターゲットは、それぞれRFを供給する。

そういうことなんだ。
さすがISO! さすが18092!!
これを読んでからNFCでの説明を見ると、確かに同じことが書かれていることがわかった。
でもなんか、18092の方が親しみを持てた。

将来的なものや特許なんかからの距離を置かないといかんから、汎用的な言葉を使ってわかりにくくなったというとこだろうね。


では、親子は?
これも18092がわかりやすい。

まず、みんな最初はターゲット。
ターゲットはRFを出さず、イニシエータからのコマンドを黙って待つ。

必要になれば、上位からの要求でイニシエータになる。
イニシエータになるとき、上位は「ActiveかPassiveか」と、通信速度を決定する。

イニシエータは自分でないRFの存在を確認する。
他のRFがあったら、自分のRFは出さない(でいいのかな?)。
なければ、自分のRFを出す。

ターゲットは、イニシエータからのRFでアクティブにされる。
Active Communication ModeだろうとPassive Communication Modeだろうと、イニシエータによるコマンド転送は選択した通信速度で行われる。
ターゲットからの応答も同様で、イニシエータの通信速度で行われる。

さて・・・ここでよくわからなくなってきた。
Active Communication Modeは、どっちもRFを出す、とある。
しかしここでは、ターゲットはRFを出さないように見える。
Activeなターゲットとか、Passiveなイニシエータって、どんな状態なの?

こんな記述があった。

Active Communication Modeの場合、イニシエータが出したRFは切られる。
Passive Communication Modeの場合、イニシエータが出したRFは切られない。

・・・わかるような、わからなくなってきたような。


なんかまた、手の中でするっと抜けていったような気分だ。

今日はもう遅いので、寝よう。
いつか近いうちに、再挑戦することになろう。

2011/02/21

[nfc][dep]LLCP準備

PHY層があらかた動いたので、次はLLCPの準備をしなくてはならない。
まあ、MACもなんかせんと行かんとは思うが、ひっくるめてやらねば。

なぜLLCの実装ではなく準備かというと、API周りが整っていないから。
コマンドのやりとりはそれなりに整えているのだが、呼び出し側がおっかなびっくりな感じだ。
でもまあ、これはLLCとしてどういうシーケンスになるかがわからないと、やる気にならん。

それより先に、やらんといかんのがある。
非同期化だ。
今のは普通のコマンド用になっているので、コマンド送信とレスポンス受信が1つのAPIになっている。
しかしターゲット系(だけじゃないかもしれんが)のコマンドは、ACKまで返して相手待ちになるものがある。
そうすると、そのコンテキストはブロックされてしまうので、困る。
ほら、キャンセルとかできんではないか。

とはいえ、非同期化するということは、なにがしかOSの力を借りなくてはならない。
Androidとcygwinで動けばいいから、pthreadでやってしまえばいいのだが。。。めんどくさい。
最終的にはAndroidで使うつもりだから、Javaと親和性がいい形がいいとは思う。
思うが、私があんまりJavaをわかっていないので、どうするのがいいかわからん。

JNIがねー、ネックなのよ。
JavaからCを呼び出すのはやれるんだけど、CからJavaのコールバックがよくわからん。
それにそもそも、Cを呼び出すのだって、javahを使うパターンや、なんかヘルパーっぽいものを使うパターンがあって、何がいいのかいっちょんわからん。

つまり・・・勉強不足ということだ。
実はLLCPの準備で一番必要なのは、Java/JNIの勉強なのかもしれん。

2011/02/20

[nfc][dep]PHY層まで

ようやく、NFC-DEPのPHY層部分が動いた。
と書くとすごそうに聞こえるが、PHY層ってのは今回はDEP_REQ/RESのやりとりをする部分になる。
つまりまあ、片方をイニシエータで、片方をターゲットで起動し、DEP_REQを送信するコマンドを使うだけなのだ。
だけなのだが、なかなかうまくいかなかったのだ。
何が原因だったかというと・・・実装ミス。
InDataExchangeにはターゲット番号が必要らしいが、抜けていたのだ。
エラーの内容が「DEPとして間違えている」という感じだったので、NFCのドキュメントを見直さないといかんのかぁとげっそりしていたところだ。
まあ、気付いてよかった(前向き)。
RC-S370をイニシエータ、RC-S620/Sをターゲットにした。









極端な話、自分で送受信両方実装してしまうのであれば、このレベルでそんなに問題はない。
このコマンドは、自分の好きなデータを送ることができるので、何かルールさえ決めてしまえばいいのだ。
しかしそれでは、他の端末とやりとりできない。
やはり、あきらめてP2Pまで実装するとしよう。
いつになることやら・・・。

グルーガンを買う

前回売ってなかったのだが、今日ダイソーに行くとグルーガンがあった。
ズキューン!
gluegun.jpg
315円でした。
グルーガンがなくて、ライターでグルーをあぶって押しつけると、なかなかきれいにならない。
ならない例を載せておこう。
mittomo1.jpg
汚すぎて、写真にしてもよくわからんですな。

[nfc][dep]予想とシーケンスが違う

予想というわけではないな。想定、くらいか。

PN533のユーザーズマニュアルを見ながら、NFC-DEPができるかどうかのテストをしている。
(DEPなんて、そんなにセキュリティと関わるところでもないように思うから、公開してくれないかなぁ。)

PN533では、InJumpForDEPなるコマンドを投げると、相手のターゲットが反応したら応答が返る、というようなシーケンス図が描かれていた。
では、とコマンドを送信してみると・・・状態がエラーで返ってくる。
なんだ?

何度やってもだめなので、ターゲットがRC-S620/Sではよくないのかと、nimocaをかざしてみたが、だめ。
携帯電話を当ててもだめ。
というよりも、かざす前にエラーになっている。
ん? もしかして・・・。

かざす前にターゲットを置いてからやると、うまくいった。
待ってくれないのか!
別のページのシーケンスを見ると、先にターゲットが立ち上がってて、そこに対してInJumpForDEPするシーケンスになっていた。。。
図の間違いなのか、待てるようにもできるのか。。。


実際の運用を考えてみよう。

データのやりとりをするというよりも、相手にデータを送るか、相手からデータをもらうか、そのどちらかになるはずだ。
そりゃ、NFC-DEPでチャットもやろうと思えばできるんだろうけど、向かい合ってるんだから話せよ!と思う。

Half-duplexなので、どちらかが親、どちらかが子になる。
その親子決めで、コマンドのどちらを誰が使うかが決まるはずだ。
うちの携帯電話(P906i)を見てみよう。

送る場合だが、「向かい合わせてください」とダイアログが出てきて、OKすると送信状態になった。

受信する場合は・・・IrDAと違ってユーザ操作がないようだ。
三者間通信と同じで、相手からの送信をトリガとして動作するように見える。

つまり、送信側がトリガを出さなくてはならない。
InJumpForDEPはPN533だとPOL_REQなりATR_REQなりを出すらしいから、それだな。
受信側は、POL_REQを受けて、急いでターゲットになるのかな。

試してみると、携帯電話に対してInJumpForDEPを受動モードで送信したときに、携帯電話が反応を示しているようだ。
能動と受動・・・。
親子だけでなく、そこもちゃんと考えんといかんですな。
ああ、めんどくさい。。。

[nfc]PaSoRiはターゲットになれない

一応動作確認のため、PaSoRiでターゲットになれるかどうかRC-S620/Sと同じコマンドを流してみた。

・・・エラーが返ってきた。

というわけで、PaSoRiではターゲットになれないようになっているようだ。
もちろん、パラメータをちゃんとしたらいけるというのはあるかもしれん。

あるかもしれんが、それでいいのだ。
きっと、危険なことができないようにチェックが入っているのだろう。
そう思いたい。

(後日)
なれないわけではない。
ここでエラーが返ってきた理由は忘れたが、ターゲットとして動くことはできる。
ただ、無線的にターゲットは厳しいよ、という話を聞いた。

[nfc]自前ライブラリをPaSoRiで動かす

前回はlibpafeでPaSoRi RC-S370を動かした。
今回は(なるべく楽をしつつ)自前のライブラリをPaSoRiで動かそう。

ベースはArduino用に出ているSONYさんのライブラリだ。
そこのシリアル通信部分をlibpafeのUSB送信に置き換えればいける・・・。

と思っていたのだが、そうは問屋が卸さなかった。
オリジナルはシリアルからそのときに必要なサイズだけ取得しているのだが、USBの場合はどうも一辺に取得してしまわないといかんようなのだ。
ACKは取ってこれるのに、なんで次はだめなのかかなり悩んでしまった。

違いはそれだけで、そこを置き換えると動いた。
RC-S620/S版と比較すると、かなり速い。
これはUSB転送が高速だからか、私の作り込みが甘いせいか・・・。


シリアル通信部分は、ifdefがたくさん入ってしまった。

cygwinでRC-S620/S向けの場合は、あまり気にせずにwrite/readさせている。
ブロックされてもいいや、という感じで。

PaSoRi向けの場合は、libpafeのUSBバルク転送を使っているAPIを呼び出している。
通信中はブロックされるのかいな?

AndroidでRC-S620/S向けの場合は、selectとかで非同期で待てるようにしている。
まあ、アプリだけならブロックされていても困りはしないんだけどね。

・・・と思ったが、よく見るとNONBLOCKにしてなかった。
cygwinでFIONREADがうまく動かんので分けたようだ。

2011/02/19

[nfc]libpafeでcygwinからPaSoRiを使う

PaSoRiはRC-S620/Sの対抗機として使う予定。
だから、自分でアクセスできないと困る。

そんなわけで、libpafeを使ってみた。
まずこれで動かせることを確認して、いるところだけ借りて中身を自分のライブラリに差し替えよう。

今回はcygwinで動かしました。


まず、PaSoRiのドライバがちゃんとWindowsにインストールされている必要があるらしい。
これは動いているから、大丈夫だ。

次は、LibUsb-win32なるものが必要だそうだ。
snapshotsとreleasesがあるが、releasesを使った。
最初はsnapshotsを使っていたのだが、どうやらインストールが必要らしく、exeだけではだめだった。
インストールすると、スタートメニューに追加されているFilter Wizardを起動する。
そしてAddの方を選び、出てきたドライバの中でPaSoRiを選択。
追加ができたら、Test (Win) Programを実行して、ずらずらと出てくることを確認しよう。

これでLibUsbの設定は終わり。


LibUsbディレクトリの中にsrcを掘り、その中にlibpafeを解凍。
他の場所でもいいような気がするが・・・試してない。

解凍したところでcygwinを起動。
cygwinを起動してパスの移動でもいい。とにかく、configureとかのあるディレクトリをカレントにする。

$ ./configure
$ make

うまくいくと、testsディレクトリの中にいくつか実行ファイルができている。
pasori_testを動かすと、バージョンが出てくる。
うちのはRC-S370だが・・・RC-S330と出てきた。
まあ、チップが同じだからだろう。

felica_dumpを実行すると、載せているカードのサービス一覧を出してくれる。
あとで答合わせをしよう。

※追記
FeliCa Secure Clientが動作していると、テストはうまく行くけどドライバ的に?だめでした。


とまあ、こんな感じで使うことができる。

libpafeのソースを見る限りでは、PaSoRiだからといって特殊なことはしていないようだ。
USBとの送受信だけお借りしよう。

[nfc]個人的なまとめ

NFCについて個人的にまとめてみた

認識はあってるかなぁ。

[felica]ドコモFeliCaのNFC対応

2011/2/18くらいに、DoCoMoさんが「こんな風にして携帯電話でNFC対応します」という記事があった。
記事とか、なんかの集まりでの発表とか。
自分なりに読み解いておこう。

概要

2段階を経る、ということらしい。

  • 現状:DoCoMoの携帯電話ではPICC/PCDとしてFeliCaしか対応してない。
  • 第1ステップ:Type-A, Bも使えるRFチップに置き換える。MIFAREなどSecureElementが必要なやつはUICC(SIM)で実現する。FeliCaのSecureElementは現状のまま。
  • 第2ステップ:FeliCaのSecureElementもUICC(SIM)に持って行く。

第1ステップ

2012年に第1ステップを実現するとのこと。
この段階ではまだFeliCaのSecureElementが必要なので、2チップ構成となる。

NFC-FとしてはSecureElementはどうでもいいのだが、FeliCaなら必要。
つまり、UPDATE(Write Without Encryption)やCHECK(Read Without Encryption)はセキュアなアクセスではないので、どこにあってもなんとかできるのだが、WriteやReadはNFC-F外なのでごにょごにょしてやらねばならない。

それ以外のSecureElementは、USIM上に持つ。
関係としてはNFC-FとFeliCaと同じだろう。
NFC-A, Bでアクセスするメモリはどこでもいいけど、MIFAREとしてアクセスするにはセキュアじゃないといかん、とか。

あー、MIFAREに対する知識が薄いなあ。
Type-A, Type-BとNFC-A, NFC-Bの位置関係が・・・。
JISで調べる必要あり>自分


第2ステップ

第2ステップで、FeliCaのSecureElementチップをなくして、USIMに持って行く。
つまりまあ、情報をUSIMに集約させることになるのか。
今でもアドレス帳やメールを本体とUSIMのそれぞれに置けるが、そんなイメージ。

そうなると部品が減らせるので、少しは安くなるかもしれない。
さらば、蔵よ・・・。

今のMobile FeliCa Chipは、特定のSecureElementチップにしかアクセスできないのかしら。
しかし、この発表はDoCoMoがやっている。SONY/FNさんじゃない。
ということは、ハードウェアとしてはアクセスできるけど、DoCoMoの仕様としてそうしている、ということなのかな。
それをUSIMにもアクセスできるように仕様変更することで対応するとか。


DoCoMoの図を見ると、第1ステップからType A, B, FeliCaに対応できるとなっている。
さて、Type-AはMIFAREを含むのだろうか?
私のイメージでは、MIFARE=Type-A+セキュアな部分、だ。
なので、MIFAREにはアクセスできない・・・と思ったけど、それではうまみがないよな。
世界標準を目指しているのだから「俺に仕組みを使えばどっちでもいけるぜ!」なのかな。

って、これってDoCoMoの発表なんだよな?
携帯電話のFeliCa仕様は、確かにDoCoMoが非常に強い。
Mobile FeliCaのハードウェア仕様も強いんだろうなぁ。
こういうしくみにしたいから、チップもそういうの作ってね、って言えるんだろうな。

NexuxSに搭載されているPN544は、たぶんMIFAREには対応してるしNFC-Fにも対応してるのだろうけど、FeliCaに対応しているのだろうか?
スペックシートを見ると、PCDとしてはFeliCaが入ってるけど、PICCとしては入ってない。
それに、どっちにせよSecureElementを持ってないんじゃないかな、PN544ではなくNexus Sが。
USIMにはアクセスできるかもしれんが、FeliCaのSecureElementは持ってないだろう。
なので、FeliCaには対応してないと考えて良さそうだ。

PN544は、PICCとしてはNFC-IP1、ISO 14443のType A, Type B、SWP経由のTypeBに対応しているようだ。
もしPN544でMIFAREのセキュアなとこにアクセスできるのなら、Type-AはほぼMIFAREと同じということになるのかな。

セキュアなところにアクセスできるかどうかは、一般人では確認できない。
いくつか手順を踏まないとアクセスできないが、その手順やデータはそれぞれのコンテンツプロバイダなどしかわからん。


端末レベルだけならそれでいいが、データ移行をなんとかせないかん。
2.0からはIDmもひっくるめて移行できるようになっていたと思うので、転送してしまえばいいのかな。
まだFeliCa付き携帯電話を買い換えたことがないので、どうやってるか知らんのだ。

インフラ周りはどうなるのかな。
EdyチャージをFeliCa以外からやれるようにする、という記事を見たような気がする。
そこらへんも、気になるところですな。

2011/02/18

[felica]SDK for FeliCa Adobe AIRをほんのちょっと

SDK for FeliCa Adobe AIRをほんのちょっと触ってみた。

なんで疲れ果てて帰ってきた2時くらいにやったのかは、自分でもよくわからん。
仕事がうまくいかんので、逃避しているのかもしれん。

偶然、FLEX SDK4がインストールされていたので、そんなに困らなかった。
困ったのは、Firefoxでダウンロードしたものを何も考えずダブルクリックしたら、Firefoxのインストールフォルダにファイルが展開されてしまったことくらいだろうか。
自己圧縮形式よりも、zipみたいなのの方が結果がわかってやりやすいと思った。

FLEX SDKにパスを通してbuild.batを実行すると、swfファイルができた。
ダブルクリックするとウィンドウが出てきた。
Pollingするサンプルらしいのでボタンを押したものの・・・何も変わらず。
よくわからんので、サンプルの説明にあるようにfdbを使ってみた。
Flash用のgdbみたいな位置づけか。

fdbで動かしていくと、セキュリティ云々といわれた。
FeliCa Proxyがどうのこうのとか。
動かすと、動いたようだ。

わーい。

いかん、目がかすんできたので、そろそろ寝ます。
明日もハードな一日になるな。。。

2011/02/16

[rcs620s]カードっぽく振る舞う

PaSoRiで使えるアプリの中に、FeliCaランチャーというものがある。
FeliCaのカードをかざすと、何らかの認識をして、アプリとかを起動してくれるのだ。

これは面白い、と思い、うちにあるRC-S620/Sでだませないかどうか試してみた。
だます、というのは表現が悪いな。
うちのR/Wでカードっぽく振る舞えるかどうか試してみたのだ。


比較的あっさりできた。。。

日曜日に法事で疲れ果てたときに作ってたので、中身は覚えてない。
そのときは、なんかだめだなーと思っていたのだが、今日は動いた。
R/Wをつけたばかりで、インストールも適当にしかしてなかったからかも。

うちにあるnimocaと携帯電話をFeliCaランチャーに登録した後、それっぽく動くように作ったソフトでR/Wを動かすと、それぞれ認識してくれた。

しかしこれは、当然のことなのだ。
FeliCaランチャーは、特定のカードに向けたソフトではない。
だから、セキュリティがかかった部分にはアクセスできない。
セキュリティがかかった部分にアクセスしないのであれば、JISで公開されている範囲でアクセスできる。

あとは、それのまねをして振る舞えるかどうかだが、RC-S620/Sではやることができた。
つまり、それだけのことなのだ。
FeliCaのセキュリティが甘いとかではなく、セキュリティがかかっていない情報でセキュリティを守ろうとすること自体が間違っているのだ。

なので私からの警告としては、「おサイフケータイが鍵代わりになります!」みたいなシステムは注意した方がいいんじゃないかな、ということである。
おサイフケータイに専用アプリをインストールするようなタイプであれば、それは鍵が必要な領域を自分で作ることになるので大丈夫だとは思うのだが(DoCoMoのみ対応、だとフリー領域があるので安心はできんが)、ICカードでもいけます、とかはあやしいかも。

とにかくまあ、業者の話だけ聞いてもあてにならないので注意していただきたいものだ。

2011/02/15

PaSoRiを買う

とうとう、PaSoRiを買った。
RC-S370だ。
黒い・・・そしてLEDがない・・・が、これは仕方がない。

PaSoRiはパソコン用、Windows用。
ソフトもいろいろと充実しているし、なにより使っていてもびくびくしなくてよい。
今まで「誰が買うんだろう」と思ってたけど、自分が買うとは思わなかったな。

なんで私が携帯電話をあまり(ほとんど?)使わないかというと、ネットを使いたくないからだ。
ネットを使うと、なんとかホーダイじゃないかぎり、使うたびに金がかかる。
それは、いやだ。
かといって、なんとかホーダイにするほど使うこともない。
ならば、なるべく使わないで済むようにしたいではないか。

このPaSoRi、ジャストシステムさんからいくつかソフトがダウンロードして使える。
「かざして転送」シリーズだ。
これがもう、私が今までちまちまやってきたことをやってくれるのだ。

何かというと、テキストや画像を携帯電話にFALPで転送してくれるのだ。
ほら、たまに会社の飲み会とかあるではないか。
URLとか地図とか書いてあるけど、まあ覚えられない。
かといって、職場から直接行ったりするので、メモしておきたい。
印刷するほどでもないし、かといって携帯電話にメールで転送するのも金がかかる。
もちろん、ブラウザからアクセスして、なんてのはもってのほかだ。

いつもは、カメラを起動して、パソコンの画面を撮影してたのだ。
地図なんかは撮影しにくかったらSDカードに保存するのだが、携帯電話からも見える構成にしないといけないので、わざわざ取説なんかを参照しながらやってたのだ。
まー、めんどくさいわ。

それがこの「かざして転送」を使うと、そんな手間が不要だ。
簡単に転送してくれる。
いやぁ、ありがたいわぁ。

そんなわけで、かなり気に入った私であった。

2011/02/13

NFC-Vなるもの

Android2.3.3では、NFC-Vなるものに対応している。
ISO 15693らしい。
(←Android関係なのは、ここまで)。

NFC-V?
いまNFCのドキュメントを読んでいるけど、出てくるのはNFC-A, B, Fの3つ。
あとは、DEP系として、NFC-DEPとISO-DEP。
Vなんて出てこない。
調べてみると、NFCIP-2でサポートされたようだ。

NFC-A, B, Fは「近接型」と呼ばれる。
近接型カードはPICC (Proximity IC Card)、近接型R/WはPCD (Proximity Coupling Device)。
JIS X 6322


そしてNFC-Vは・・・「近傍型」と呼ばれるはず。
近傍型カードはVICC (Vincinity IC Card)、近傍型R/WはVCD(Vincinity Coupling Device)。
JIS X 6323

PICCは「proximity card」となってたけど、ICを間に挟めた方がわかりやすいので、そうした。
すまん。
「vincinity」は、近所、などと訳すらしい。
neighbourhoodよりも形式的だとか。
そして「proximity」は、近似とか近接とか近傍とか・・・。
私にはproximityとvincinityの使い分けがわかりませんわ。

NFC-Vは、NFC Forumからダウンロードできたら読むかもしれない。
が、まだその余裕がない。
とにかくわかるのは、うちにあるようなR/WではVCDになれない、ということだ。
距離も違うだろうし、周波数も違うだろう。
あ、周波数は同じだった!
まあなんにせよ、R/Wのサポート範囲に入ってないからだめだろうな。

しかし、もしNFC-V=ISO 15693だったら、おおざっぱすぎないだろうか。
だって、PICCはNFC-A, B, Fと3つあるのに。
それならいっそのこと、NFC-P(PICC)として共通なものもつくってほしいくらいだ。
まあ、そんなの作ったら「またサポートせないかんもんが増えたやんか!」と思われそうだけど。
携帯電話の仕事をしていないので、気にしない気にしない。

2011/02/12

[nfc]NFCID3とNFCID2の関係

NFCID3というものがある。
これは、NFC-DEP(NFCのデータ交換プロトコル)で使われるものだ。
ATR_REQとかでやりとりする。

NFCのDigitalProtocol仕様書を読むと、NFC-FでのNFCID3について記載があった。

  • Initiator : ATR_REQのNFCID3先頭8byteはNFCID2と同じ(MUST)
  • Target : ATR_REQのNFCID3先頭8byteとNFCID2が不一致であれば無視(MUST)

と私は読んだ(後者は不安あり・・・)。

私の解釈が正しいのであれば、NFC-Fに限れば、NFCID2とNFCID3は一緒にできることになる。
バッファ10byteだけ用意してやればいいのかなぁ。。。
気にはなるが、同じになっていて悪いわけでもないと思うのでまとめておこう。

2011/02/11

[nfc]NFCでデータ交換するまでに

LLCPしてみよう!とドキュメントを読んでいた。

読み進めていってようやくわかったのだが、LLCP仕様書を読んだだけではデータ交換できないことがわかった。
LLCP仕様書で定義しているのはOSIモデルでいうところのデータリンク層のうち、IEEE802.2にあたるLLC副層についてのみ定義されていると思われるのだ。
なぜ「思われる」なのかというと、IEEE802.2を読んでないから。。。


私の理解では、LLCP仕様書に書かれているのは、これこれこういう種類のPDU(Protocol Data Unit : やりとりするデータの塊みたいなもの)を用意して、このPDUにはこういうデータが、このPDUにはこんなデータがあるので上手にやりましょうね、という感じ。

PDUタイプのIとUIに、ユーザが送りたいようなデータをひっつけられるようだ。
で、このPDUはどうやって送るの?


PDUを送るのは、PHY層になる。
PHYは「NFC Forum Digital Protocols」とあるので、それを読む。
ISO-DEPとNFC-DEP。
この2つのプロトコルを使えばいいようである。

ISO-DEPは、Type-4A, 4B用。
NFC-DEPは、NFC-A, NFC-F用。

ISO-DEPについてはあまり書かれていない。
これは、ISO/IEC 14443を参照しろということのようだ。

NFC-DEPについては書いてあることが多いが、基本的にISO/IEC 18092を参照しろということらしい。
なので、JIS X5211を見てみた。
パケットの説明についてはDigital Protocolにも同じようなことが書かれている。
違いは、JIS X5211にはシーケンス的なものが書かれていること。
これがないと、まったく何もできない。
(前に書いたけど、WUP_REQなんかはNFC-DEPに書かれてなかったけど、いいんかいな?)

ただ・・・この文書だけでデータ交換するのは厳しい。
X5211に書いてあるのは無線プロトコルなので、これをRC-S620/Sのコマンドに置き換えなくてはならない。
ここはまた、PN533のコマンドが使えるのか見ていくしかなさそうだ。

さて、ここまでで下回りはだいたい見なくてはならない範囲がわかったと思う。
ではでは、一体なんのデータを送ればいいの?


ここで、NDEFが出てくる。
NFC Data Exchange Format。
なんとなくカード上のメモリに書き込んでおくときのフォーマットと思い込んでいたのだが、データ交換するときの基本構造になっているのだ。
まだ読んでないけど、アプリ層的な位置づけになるのかな。


そんなわけで、私が「LLCPする」といっていたのは、「NFC-DEPを使ってLLCPを実現し、NDEFデータをやりとりする」ということになりそうだ。

これ、ほんとにやるのー?ってくらい、大変そうな香りがしている。
Android2.3.3になってandroid.nfc.techってのができたから、そこにあわせたりしないと・・・。

と思って見たら、サポートされてるのはISO-DEPやん!
NFC-DEPじゃないんだ。。。
ここら辺は、海外の携帯電話がそうなってるからなんだろうなぁ。。。

[nfc]POL_REQとWUP_REQ

DigitalProtocolを見ていると、XXX_REQ/RESというのがたくさん出てくる。
気になっていたので、今頃になってみてみた。

JIS X5211にも出ているが、これはプロトコルで、何とか要求とその応答にあたる。
NFC-DEPに相当するのかな。
ふーん。

NFCIP-1にあって、NFCにないのが「WUP_REQ/RES」。
これは、Activeモードの時にイニシエータが発行するコマンドらしい。起きろ、と。
そしてどちらにもないのが「POL_REQ/RES」。
調べてみると、これはFeliCa用っぽい。ECMA-362に出ていた。
ECMAはPassiveモード時にPOL_REQしてからPOL_RESするまでの時間を調べるテストをやってるみたい。

パケットをいろいろと見ていった感触でしかないが、MIFAREとFeliCaの違いは通信速度で見分けようとしているようなのだ。
「MIFAREとしてアクセス」というパラメータではなく、「106kbpsで通信する」という形。
ECMAにあったPOL_REQも、212k/424kbps用って形だった。
R/Wに投げるポーリングコマンドの5byte、あれはPOL_REQのパラメータなのだ。

DigitalProtocolでは、POL_REQ/RESは出てこず、SENSF_REQ/RESになっている。
まあ、同じものということだな。
ここら辺を理解しておかないと、仕様書を読んでいても混乱してしまう。
せっかくR/Wとかのコマンドがこの辺をラップしてくれているのだが、DigitalProtocolは無線側のコマンドしか出てこないので、対応が付かないのだな。

WUP_REQは・・・ALL_REQで代用できるのかな?


そんなのを読んで何をしているかというと、LLCPだ。
ドキュメントを読んでいっても、やりとりするデータの構成についての話が載っているだけで、最終的にどうやってデータをR/Wに渡したらいいのかが見えてきてなかった。

んで、ようやく到達したのがDEP_REQ/RES。
ISO 18092って単語もあったのでJIS X5211を見ていくと、ようやくつながりが見えてきたというところ。

先は長いなー。

[nfc]記事を一部保留にした

RC-S620/Sをターゲットにする記事を載せていたが、一時的に保留にした。
たぶん、今は見えてないはず。

なんでかというと、案外と危険なコマンドではないか?ということに思い至ったからだ。
日曜日にPaSoRiを実家から持ち帰るので、動作確認してから削除するかどうか決めよう。

「マーケティングの除外」って、効いているのか?

ほんとに「一応」という感じではあるが、Androidアプリを公開している。
最近はPCからも見えるようになったので、一応リンクだけしておくが、役に立つものは1つもない。

アプリを公開するときにいろいろと入力する項目がある。
そこに「マーケティングの除外」というのがあって、これにチェックするとGoogle所有のサイトでしかアプリが宣伝されなくなるらしい。

特に宣伝したいわけでもないのでチェックを入れたのだが、これは有効になっているのか?
このオプションが追加されたときにチェックしたのだが、ときどきメールで「うちで公開しました-」というような連絡が来る。
それが嫌だからチェックしてるのに!

2011/02/08

[nfc]DigitalProtocolでの微妙な表現の違い

一番よく読んでいるNFCのドキュメントは、DigitalProtocolだ。
これを中心に、他のドキュメントを読むという流れにしている。
このDigitalProtocolの目次を見ると、表現に微妙な違いがあることに気付いた。
  • NFC-A, B, Fは「Technology」
  • Type 1 Tag~Type 4B Tagは「Platform」
  • ISO-DEP, NFC-DEPは「Protocol」
Technology、については、用語にあった。
NFC標準として決められた送信パラメータのグループ、らしい(他にも書いてあるけど。。)。
Type1 Tagとかは、Technology Subset、となっている。
Technologyの一部としてサポートされたレガシープラットフォーム、とのこと。
ほほー、というくらいにしかわからないのが、ちと悔しいですな。
結局のところ、今のところNFCを実現させるには、どれかのPlatformを使うしかないと思う。
なにもない「NFCのカード」というものがなさそうだからだ。
NFCは共通規格であって、統一規格ではないんだなー、というところなのかな。
さすがにこれだけの利害関係が絡むものを、規格として統一させるのははばかられたに違いない。
あとは、デファクトスタンダードとか、そんなのになるのかなぁ。
そのうち、MIFARE-FeliCa間の両替商なんか現れたりして。
「うちのサービスを使うと、手数料が安くなりますよ」とか。

[nfc]LLCPの略語に挫折・・・

インテントのPUSHができたようで、非常におめでたい。
ターゲットで起動する方法もわかったので、

LLCPのドキュメントを読み出した。
略語や用語が多いので、まずそちらを整理するか、と眺めてみた。

CC・・・Connection Complete
RR・・・Receive Ready
RW・・・Receive Window

いかん、こりゃわからんわ。
こんなのもあった。

I・・・Information

略しすぎだ・・・。
そんなわけで、略語集を作ることを試みていたが、そうそうに挫折した。

2011/02/07

[nfc]ターゲットにするのに一番安上がりな方法は?

こんだけいろいろと試していると、そろそろR/Wが1台だけだと寂しくなってきた。
かといって、RC-S620/Sをもう1台買うのも、あまり芸がないし、ホストを買ってやらないといかんので金がかかる。
ここは、何か違うものを検討してみよう。

最初に出てくるのは、やはりSDB-200だろう。
が、一般では買えないので、すぐに却下。

その次は、FeliCa Plugかな。
これはもう、ターゲットだから、期待するものに近い。
だが・・・機能があまりなさそうだ。
値段相応といえばそれまでなのだが、NFC-Fとして必要な最低限の機能しかない。
つまり、Pollingと読み書き。
製品としてNFC-F機能を載せたい、というのであれば十分だが、遊びで使うにはちと寂しい。
保留だな。

その次が出てこない。。。
NexusSか。PN544が載っているらしい。
PN544はR/W用ではなく、カード用のような気がする。
まあ、両者の区別はあまりないのかもしれんが・・・。
Gingerbreadで盛り上がっているのはこの端末なので、遊び相手としては十分かもしれん。
かもしれんが・・・却下だ。
理由は、携帯電話だから(電話きらい)。

となると、PaSoRiか。
同じR/Wタイプやん、と思われそうだが、PCにつなぐことができるのは大きい。
なぜかといえば、FeliCaのR/Wを正式に対応しているのはPCソフトしかなさそうだからだ。
やっぱり、リファレンス機は必要よね。

というわけで、Amazonで注文した。
一緒に部屋の蛍光灯も注文したのだが、値段があまり変わらんのだな。

2011/02/06

[rcs620s]ターゲットになることはできた(修正)


RC-S620/SにPN533のコマンドを突っ込んで、ターゲットにすることはできた。


ポイントは、MIFAREの部分。

まずSENS_RES。
これは、0x00 0x01~0x00 0x08はよさそう。
0x00 0x00はNG。
NFCのDigitalProtocolにSENS_RESが載っているのだが、エンディアンがよくわからん。
JIS X5211では2byteとして書かれているのだが、DigitalProtocolは2byteとして書かれている。
これを見比べると、リトルエンディアンのようだ(PN533でもLSB firstとあるし)。
ならば、SENS_RES=0x0100~0x0800はOK。
1~4のところは「独自仕様の符号化」とあるが、意味がわからん。

そしてSEL_RES。
これは、0x08はNG。0x40はOK。
0x40は「NFCID1は完全。ターゲットはNFC転送プロトコル互換。属性要求に対する処理能力あり」。
0x08は「NFCID1は完全。ターゲットは転送プロトコルに非互換。属性要求に対する処理能力なし」。
互換が無くては処理できない。


(追記)
なお、「0x00でいい」などというのは、あくまでRC-S620/S側の動きである。
そっから先は、相手側も絡んでくる。

2011/02/05

[PN533]PN533ターゲット起動コマンドのGt

最初に断っておくが、これはNXPからダウンロードしたPN533のユーザーズマニュアルを読んだ感想だ。
他のR/Wについてはまったく関係がありません。
PN533をターゲットとして起動するのは、TgInitAsTargetというコマンド。
コマンド構成はドキュメントを見てもらうとして、ここにGtとTkというパラメータがある。
これが説明を読んでも、なんか煮え切らない。
JIS X5211を読んでいると、略語にGtがあった。
「ターゲットの任意選択情報フィールド」らしい。イニシエータだと、Gi。
PN533のGtは、このことなのか?
ユーザーズマニュアルには「ATR_RESで使用するgeneral bytesとある。
general bytesっていわれてもねぇ。。。
英語のユーザーズマニュアルで検索しても、length、ばかりヒットして見つからんし。
ATRも略語に載っていた。属性、Attributeのことらしい。
(なんか、略しすぎ。ATTRくらいであってほしい。)
ATR_RESはATR_REQの応答。
GtはInJumpForDEPコマンドの応答にも出てきた。
このコマンドは、ホスト(ここではPN533)がターゲットをActive/Passive Communication Modeで起動させるためのコマンドらしい。
おお、Active/Passiveは偶然にも調べていたな。
ともかく、Gtはターゲットが「私はこんな属性ですよ」という意味を持った値なのだろう。

10章にプロトコルの流れが書いてある。
対象になっているのはNFCIP-1デバイスらしいが、これはカード側のことだろうか?
PN533はR/W用なので、デフォルトだとイニシエータだと思う。
あるいは、それも含めてNFCIP-1デバイスなのだろうか。
なぜそんなことを書くかというと、「いかなるNFCIP-1デバイスも、初期状態は、ターゲットモードでなければならない」とあるからだ。
その後に「アプリケーションの要望に応じる場合には、イニシエータモードに切り替わってもよい」とある。
R/Wの動きは、この部分まで実行していると考えていいのかなぁ。
11.2 受動通信モード
11.2.1 106kb/s
11.2.2 212kb/s or 424kb/s
11.3 能動通信モード
となっているので、NFC-AかNFC-Fかは、ポーリングコマンドとかそんなのではなく、通信速度で決まるようだ。
最初にやりとりするのは、ATR-REQ→ATR_RESらしい。
ATR-REQに出てくるのが、NFCID3。NFC-DEP用のIDだ。
そして応答のATR-RESを見ると、Gtが出てくる。
が、説明は「汎用バイト」。しかも、汎用バイトを使用するかどうかのビットまである。
ってことは、TgInitAsTargetでのGtも同じことか。。。
プロトコル仕様として決められているのかと思って読み進めたんだがなぁ。。。

[nfc]R/Wにとっての通信モードは能動か受動か

JIS X 5211という規格書を見ている。
これは、ISO/IEC 18092、通称NFCIP-1を基に、技術的な内容を変更せずに作成したものらしい。
どのくらい何が違うのかはわからないが、それを信じよう。

JISのこのページ、とリンクできればいいのだが、どうもやり方がわからない。
検索したページはその場限りのもので、X5211のページもその場限りみたい。
うーむ。
http://www.jisc.go.jp/app/JPS/JPSO0020.html
ここから「x5211」を検索し、出てきたリンクをクリックするとPDFが開いて読める。

開いて読めるのだが、私の場合はAcrobat Readerではないプラグインを入れていたため、苦労した。
全部のプラグインを解除して、Acrobat Readerに関連づけし直す、ということをやってようやく読めた。


ここの用語欄に、「能動通信モード」と「受動通信モード」がある。
Active Communication ModeとPassive Communication Modeだ。
どちらの説明でも、イニシエータはRFを出すことになっているが、ではR/Wにとっての通信はActiveなのかPassiveなのか。

という意味のないことを考えていた。
ここの通信は、あくまで相手がいる場合のこと。
そして、相手がいる以上、どちらかがイニシエータになり、どちらかがターゲットになる。
なのでこの用語は、ターゲットが存在して初めて意味があるのだな。

そうすると、ターゲットがActive Communication Modeで動いてきたとき、イニシエータもActive Communication Modeになるし、PassiveになるならイニシエータもPassive。
それでいいのかな。

R/Wをターゲットとして起動する場合は、それはイニシエータではなくなる。
だから、R/Wだからどうのこうのではなく、ターゲットかイニシエータか、という役割で読まないといかんのだ。

うーん、RC-S620/Sをターゲットにできないので、何かヒントがないかと細々探っているところ。

[nfc]NFCID (1)

NFCのID。
MIFAREならUID、FeliCaならIDmにあたるもの。
NFC-A, B, F, DEPにそれぞれある。
名前は、こう。
  • NFCID0 ... NFC-B用。4byte。
  • NFCID1 ... NFC-A用。simple:4byte / double:7byte / triple:10byte。
  • NFCID2 ... NFC-F用。8byte。
  • NFCID3 ... NFC-DEP用。10byte。
NFCID1はMIFAREだが、4byte版はUIDではなくなるそうだ。
4byteで大丈夫なのか?と心配していたのだが、昨年の7月にお触れが出ていたようだ。
NFCID0はいいのかな?
また、NFCID1には「カスケードレベル」なるものがある。
それはなんだかよくわかってない・・・。
書くときは「NFCID1 CLn」と、nがレベルに当たる数字になるようだ。
これは4byte固定らしい。
NFCID2がSystemCodeごとにあるようなものかな?
NFCID2は、先頭2byteで情報がわかる。
  • 01 FE : NFC-DEPプロトコルサポート
  • 02 FE : Type3 Tagサポート
  • 03 FE : FeliCa Plug
  • それ以外 : Type3 Tagサポート。プロプライエタリ。
らしい。
うちにあるのは「それ以外」だった。

[rcs620s]エラーが返る

まあ、前も書いたが、RC-S620/Sをターゲットとして動かそうとしているのだが、うまくいかん。
なんとかしたいのだが、どうしていいのかわからないのも事実。

FeliCaに対して「もっと(開発系の)情報くれー」と思うが、全体的に見るとそんな人は少ないだろう。
いたとしても、純粋な開発者だけでなく、よからぬ悪だくみを考えている人もいるかもしれない。
そう考えると、危険を冒して公開するよりも非公開を選んだ、ということかなぁ。

それはさておき。

返ってくるのは、エラー。
これが、どんなエラー、というものがない。
エラー、というだけだ。
ほら、ユーザIDとパスワードを入力して失敗しても「ログインできません」しか出ない。
あれと同じだ。
何が間違っているかを説明することは、それだけ悪い人につけいる隙を見せることになってしまう。
だから、エラー、としかいわないのだろう。

だろうけどさ・・・・。
せっかく開発用に購入したのに、使い方の資料が入手できないというのはあんまりだと思う。
もちろん企業向けであれば、それなりに手段はある。
でも、私は個人的にこれを買ったのだ。
ならば、個人でなんとかするしかない。

んで、思いついたのが、犯罪にならない範囲であれこれ調べる。
それしかないといえば、そうなのだが・・・。
私は今まで、かなりお上品な方法で調べてきていると思う。
もちろん、それまでのことがどうなのかは別だが、とにかく見た目上はそうだ。
しかし、もう少し技を使ってもいいんではないかと思った。
どんな技?と訊かれると困るのだが、とにかく犯罪ではない範囲だ。
犯罪は、理屈に合わないからな。

では最後に、画像の載せ方の練習をして終わろう。
載るかな?

fish.jpg

エラーの出方には気をつけよう。
フォーマットが違うからエラーなのかと思っていたが、パラメータの値が受け付けられない場合も同じくエラーだった。
とにかく、アプリっぽいエラーは、全部「エラー」扱いなのだ。

ふいー、これからどうしようかねぇ。

2011/02/03

[rcs620s]ターゲットにさせる方法がわからん

RC-S620/SはFeliCaのR/Wだが、Type-AやType-BもR/Wできる。
それだけでなく、なんとターゲットとしても動かすことができるのだ!
が・・・やりかたがわからん。
コマンド番号はドキュメントにあるのだが、パケットのフォーマットは書かれていないのだ。
そういう場合どうするかというと・・・よそから情報をもらうしかない。
以前作成したPUSHなんかは、SONYさんがライブラリを出していたので、それを参考にしたのだ。
しかし、今度はそういうわけにもいかない。
PN533のフォーマットと同じに違いない!と思ってやったが、だめ。
そもそも、PN533のフォーマットも可変なところが多く、そこをどうしていいかがわからん。
とりあえず全部0x00にしたけど、だめ。
次はModeをforで全パターン回したけど、だめ。
最後にGtとTkを2重ループで全パターン回したけど、だめ。
うーむ。
これはそもそも何かが違うか、PN533であってるけど足りないのか、そのパラメータの値がだめなのか。。。
どれもあり得そうで困る。
これができないと、PUSHを受信させるテスト(あそび)ができないじゃないか!
もうちょっとがんばろう、明日。

2011/02/02

[llcp]LLC PDU

実は、しばしばLLCのドキュメントを読んでいる。
もちろん仕事ではなく、個人的にだ。

今日は、「4.1 LLC PDU Format」から引用。

DSAP PTYPE SSAP Seqence Information

6bit

4bit

6bit

0 or 8 bit

byte[]

これが、PDUのフォーマットらしい。
Protocol Data Unit。
FALPはどうだったっけ?とネットで資料を探してみたが、さすがにない。
NDAはなかなかに守られているようで、安心した。

SAPはService Access Point。
DはDestination、つまり宛先。
SはSource、つまり送り主。

PTYPE、これがパケットの中身を端的に表している。
なぜ最初にDSAPがあるかというと、データ受信の処理に関係している。
受信側がこれらのデータを受けとるのだが、全部受信しなくても、先頭の6bitまで受信できた時点で、自分宛かどうかが判断できる。
早めに判断できた方が、いろいろといいのだ。

とにかくまあ、ここから始まることがわかってもらえばいいかな。

2011/02/01

こんばんは

以前のブログが有料化されたため、移転してきました。
皆様、よろしくお願いします。

しばらくは見つからないようにやっていきます。