NFCなどのRFIDを使って実験やら何やら遊んでみました。
昨年はコロナの影響で残念ながら中止となってしまった自動認識展ですが、
今年は無事に開催とのことで弊社も2年ぶりの出展となります。
例年通り、こじんまりとしたブースにゴチャゴチャ、っと色々ならべる感じになるかと思います。
そういえば前回は、何故かプレミアムのついたスニーカーを展示して、
いろいろあってテレビの取材でも取り上げていただいたのでした。
https://youtu.be/35llff7Xogc?t=246
今回は謎のブロックが並ぶ予定です、果たしてどんな仕掛けなのか。
ぜひ現地でご体感ください。
自動認識総合展は、10月の6〜8日まで東京ビッグサイトの南館で開催されます。
https://www.autoid-expo.com/tokyo/
センサーを搭載した RFID タグはそれなりに登場してきているんですが、その中の一つに farsens のタグがあります。
このタグはIOが付いていて、そこに別途センサーを接続することで測定ができるという面白い使い方ができます。仕様を見るとここに繋いだセンサーの抵抗値を値として取得できるようです。
タグのユーザ領域にデータが保存されますので、専用のリーダは必要なくどんなUHFのリーダでも読み取ることができるのもこのタグの特長になってます。
最近エクセルツールに対応した Apulsetech のリーダで試してみます。
エクセルツールをちょっと改良して、タグの値を取得できるようにしてみました。
まずは何も繋げずに測定してみます。
次にショートさせてみます。
次は両端を手で握って図ってみます。
とある案件で RTK を使った位置測定のデバイスを作成したんですが、これがいろいろ使えるということで今回は納品した器材をお借りして実際に測定をやってみました。
ちなみに RTK は GPS のごっついみたいな感じで、ｃｍ単位で位置の測定ができるというスグレモノです。ドローンの位置制御みたいなのに使われてます。
こちらがデバイスになります。
こちらのデバイスは各デバイスの通信として LoRa を使用している所が大きな特長になります。通常の RTK では、基準局のデータをリアルタイムに移動局に渡して移動局が位置の計算を行います。この方法では基準局のデータを移動局に渡すため、基準局と移動局が通信できる必要があります。この通信はWifiを利用していることが多く、測定位置がWifiの通信範囲に縛られます。
今回のデバイスは基準局のデータを移動局に渡さず、すべてのデータをクラウドに集めて計算するようになっていますので、各機器は通信用の親機にデータを投げればよく、この通信に LoRa を使用しているため、数キロ離れた場所でも測定が可能になります。
数キロ離れた測定は検証が大変なので近い距離で試してみます。
駐車場に設置。親機は Wifi でインターネットに接続する必要があるので向こうにある建物に設置してあります。
結構なデータ量を LoRa で送らないといけないんですが LoRa は通信に時間がかかる上、複数の機器が（チャンネルが同じ場合）同時に通信できないので、PPS を使って正確な時刻計測を行い、送信時間を各機器が分割することで各機器の送信が被らないように各機器が制御を行っています。
電源をONして５分程度すると、だいたい位置がFIXしてきます。
これから計算すると、子機１と子機２の距離は５．４６ｍだそうですので検証してみましょう。
RFIDを使って在庫管理をしようと思ったとき、在庫データの持たせ方は大きく2つに分類されると考えています。すなわち、
最近 LoRaWAN を触ることになったんですが、通常は The Things Network を LoRaWANサーバとして利用しますが今回は The Things Network を経由せずに Microsoft Azure IoT Hub に接続したいという特殊な状況になってしまったためいろいろやってたんですが、これがえらいハマってしまったので記録として残しておこうと思いました。
使用する LoRaWANゲートウェイは DRAGINO の LPS8 です。
設定画面をいろいろ見ていると、Azureとかの設定もあるしこれは簡単にできそうだなーと思ったら全く違っていろいろ大変でした。
まずは端末の認証ですが、ゲートウェイ単体では OTAA(Over-the-Air Activation)はできませんので、ABP(Activation by Personalization)を使うことにします。ABPの設定は端末ごとに DevADDR、APP Session Key、Network Session Key の３つを設定画面で設定して、同じ値を端末に設定すればOKです。
以降、設定画面のキャプチャ掲載しますがファームの更新が結構頻繁にあるようなので実際とは異なる可能性あります。掲載時点でのファームのバージョンは lgw-5.4.1628078462 です。
ABPの設定をしたら、LoRaWAN Configuration の画面に移ります。Service Provider のところに、Built-in for ABP Decode to MQTT というまさしくそれな的なのがあるので選んで保存します。
この辺のマニュアルを読んでみると、Azureへの接続にはSASを利用しているように見えます。ただSASには有効期限があって、できるだけ短く（１時間とか）にするのがお作法のようで、設定しても１時間で繋がらなくなるなどになってしまうのでそれでは困るなーというわけでX.509証明書の方でやってみることにします（証明書も有効期限ありますがこちらは長く設定できるので）。
X.509証明書で接続するためにいろいろやんないといけないんですが、こちらのチュートリアルが比較的簡単に実行できました。
https://docs.microsoft.com/ja-jp/azure/iot-hub/tutorial-x509-scripts
上記チュートリアルを実行した前提で話を進めます。
接続には３つのファイルが必要になります。Azure の CA認証ファイル（ゲートウェイにデフォルトでインストールされている Azure.cer です）と、上記のチュートリアルで作成したデバイスの認証ファイル２つ（cert/new-device.cert.pem と private/new-device.key.pem）です。デバイスの認証ファイルはあらかじめゲートウェイにアップロードしておきます。
Azure設定画面を見てみると、CA認証ファイルの設定しかありません。やはりSASを利用する前提のようです。
# ------------------------------------------ # Call MQTT Publish command # 1. Case with User, Password and Client ID present (e.g. Azure) if [ ! -z "$pass" ] && [ ! -z "$user" ] && [ ! -z "$clientID" ]; then case="1" mosquitto_pub $D -h $server -p $port -q $pub_qos -i $clientID -t $pub_topic -u $user -P "$pass" $C $cafile $PUB_FLAG "$mqtt_data" # 2. Case with Certificate, Key and ClientID present (e.g. AWS) elif [ ! -z "$certfile" ] && [ ! -z "$key" ] && [ ! -z "$clientID" ]; then case="2" mosquitto_pub $D -h $server -p $port -q $pub_qos -i $clientID -t $pub_topic --cert $cert --key $key $C $cafile $PUB_FLAG "$mqtt_data" # 3. Case with no User, Certificate or ClientID present elif [ -z "$user" ] && [ -z "$certfile" ] && [ -z "$clientID" ]; then case="3" mosquitto_pub $D -h $server -p $port -q $pub_qos -t $pub_topic $PUB_FLAG "$mqtt_data" # 4. Case with no User, Certificate, but with ClientID present elif [ -z "$user" ] && [ -z "$certfile" ] && [ ! -z "$clientID" ]; then case="4" mosquitto_pub $D -h $server -p $port -q $pub_qos -i $clientID -t $pub_topic $PUB_FLAG "$mqtt_data" # 5. Case with User and ClientID present, but no Password and no Certificate present elif [ -z "$pass" ] && [ -z "$certfile" ] && [ ! -z "$user" ] && [ ! -z "$clientID" ]; then case="5" mosquitto_pub $D -h $server -p $port -q $pub_qos -i $clientID -t $pub_topic -u $user $PUB_FLAG "$mqtt_data" # 6. Case with User and Password present, but no ClientID and no Certificate present elif [ ! -z "$user" ] && [ ! -z "$pass" ] && [ -z "$clientID" ] && [ -z "$certfile" ]; then case="6" mosquitto_pub $D -h $server -p $port -q $pub_qos -t $pub_topic -u $user -P "$pass" $PUB_FLAG "$mqtt_data" # 0. Else - invalid parameters, just log else case="Invalid parameters" logger "[IoT.MQTT]:Invalid Parameters - mosquitto_pub not called." fi
今回は NDEF に関する内容です。NDEF というとスマホで URL を書き込んだりして利用しますが使用しているタグは NTAG213 だったりが多いと思います。
NTAGシリーズは Mifare の後継で NFC Forumでは Type2 のタグになります。そんなわけで NDEF は Type2 のタグだけしか使えないのかというとそういうわけでもなく、ISO15693 のような Type5 のタグでも使うことができます。
最近 NDEF のロックを使う機会があったのでロックってどうやるんだったっけかなー、確か Capability Container に設定するのが簡単だったよなー、でも実際どうやるんだったっけーといろいろ調べてたら Type2 と Type5 でロックの仕方が異なるということに気づきました。
ちなみに Capability Container ですが、
前回のアレクサガジェットのときは、ESP32 マイコンと RFID リーダは Bluetooth の SPP で接続していました。ESP32 は Bluetooth も内蔵しているので、そのままで SPP や BLE のリーダを使うことが出来ます（通信仕様は調べる必要がありますが）。
その後いろいろありまして、今度は USB 接続のリーダを利用する必要が出てきました。もちろん ESP32 マイコンには USB ホストコネクタありませんので、USB ホストのモジュールを使う必要があります。
モジュールはいくつかあるようなんですが、スイッチサイエンスさんにM5Stack用のシールドがありましたのでこれなら情報もそれなりにありますし何とかなるだろうと思って使ってみることにしました。
回路図とにらめっこしながら作成したのがこれ。
プログラムはライブラリの USB_Host_Shield_2.0 がそのまま使えるということでサンプルプログラムの USBFTDILoopback を使います（つないでいるUSBのリーダがFTDIなので。このリーダはSPPだけでなく、USB接続して仮想COMポートで制御できます）。このサンプルでは特定のデータを送信して受信するのを繰り返すようになっています。そこで送信するデータを下記のリーダのバージョン取得コマンドに書き換えておきます（６５行目）。
早速動かしてみると、動いてはいるようですがコマンドを投げているような気配はありません。何が起きているのかわからないのでデバッグモードにしてデバッグ出力するようにします。settings.h の４２行目あたりの次の値を０から１に変更すればいいようです。
これで動かしてみると、
FTDI Init
FTDI Init: Product not supported
Expected VID:00000403
Found VID:0403
Expected PID:6001
Found PID:6015
このような表示でました。どうも PID が合ってないようです。ということでソース側のPIDを変更します（cdcftdi.h の２９行目あたり）。
もう１回動かします。
FTDI Init
Addr:01
NC:01
Conf.Val: 01
Iface Num: 00
Alt.Set: 00
Endpoint descriptor:
Length: 07
Type: 05
Address: 81
Attributes: 02
MaxPktSize: 0040
Poll Intrv: 00
Conf.Val: 01
Iface Num: 00
Alt.Set: 00
Endpoint descriptor:
Length: 07
Type: 05
Address: 02
Attributes: 02
MaxPktSize: 0040
Poll Intrv: 00
NumEP:03
Conf:01
baud_value:001A
baud_index:0000
FTDI configured
.~Rv0000bl-7.2.6.2
.~Rv0000bl-7.2.6.2
.~Rv0000bl-7.2.6.2
.~Rv0000bl-7.2.6.2
.~Rv0000bl-7.2.6.2
.~Rv0000bl-7.2.6.2
.~Rv0000bl-7.2.6.2
キター！リーダからバージョン情報のリプライが来ています。これで ESP32 マイコンからUSB接続のリーダが利用できるようになりました。
MANICAモバイルのゲートを作るというのを以前やったんですが、これをちゃんと作りたいということで何で作ろうかと考えたんですが、やっぱり手頃なのがなくてそういえばアレクサとか Google Nest とか最近どうなってるんだろうと思ったら、アレクサのガジェットが作れるようになっていました。
詳細はこちらに詳しく記載されておりますので参照くださいませ。
ESP32をAlexa Gadgets Toolkitデバイスにしよう
RFIDリーダとガジェットを直接接続するのは無理ですが、ESP32とRFIDリーダを接続すればガジェットとして使えそうです。ちなみにガジェット自体は上記リンクの内容で問題なく動いたんですが、なぜかスキル側でエンドポイントの取得が全然できなくて一旦諦めたんですが数日後にやってみたらあっさり取得できたので進めることができました。
こんな構成になります。
まずは家の中で使う想定で、これを使ってカギとかサイフとかを探せるようにしてみたいと思います。
・・・
というわけで作成してみたんですが、実用レベルには至らなそうな結果になってしまいました。
私「アレクサ、ICタグでカギを探して。」
アレクサ「わかりました。」 ここでリーダが自動で読み取りを開始する
アレクサ「ありませんね」
アレクサ「ありませんね」
アレクサ「反応あり」 （タグが読めた）
アレクサ「反応あり」
アレクサ「近い」 （RSSIが大きくなった）
アレクサ「近い」
アレクサ「そこ！」 （RSSIがさらに大きくなった）
アレクサ「そこ！」
私「あった」
アレクサ「よかったですね！」 ここでリーダの読み取りは停止
という動きになるんですが、なんともリアルタイム性が無いので探しづらいです（笑
ESP32側ではリアルタイムに判定できるんですが、その結果をガジェットで上げるとクラウドのスキルまでいって、そこから話すことばを選んでアレクサに降りてきてようやく話すという感じなので判定からアレクサが喋るまでどうしてもラグが出来てしまいます。
アレクサは言葉のやり取りをする前提なのでリアルタイム性を求めるのは難しいかもしれません。何かもうひと工夫必要ですね。
前回、Windows PC上でWi-Fi Directを使って、VPN経由で通信してみました。今回はmacOS上でインターネット共有を使って、VPN経由で通信してみようと思います。短いです。RFID関係ありません。
このシリーズもかなり間が空いてしまいました。前回の「EPCの謎に迫る その３」は２０１６年ですから何と５年も！ お久しぶりです。大変恐縮でございます。
しかしだからといって謎が無いわけではありません。いっぱいあります。今回は謎の多いマスクについて迫りたいと思います。
マスク機能は標準で付いてる機能で、例えばEPCがXXXXで始まるものだけ応答させるとかそんな風に使います。わけのわからないタグがいっぱいあるところで、必要なタグだけ読みたいという感じですね。もちろん全部読んじゃって、受け取ったあとでソフトウェア側で無視するということもできますがタグがワサワサあるところでは使った方がいいんじゃないかと思われます。
マスク機能がどのように働いているのかは結構謎だったりしますよね。しかも結構複雑だったりします。
例えばこれ
RF-BlasterというUHFリーダのデモ用アプリでマスクの設定をしようとするとこんな画面が出てきます。Bank とか Offset とか Mask とかは何となくわかりますが、Selection Flag とか Action とか、は？って言うのが出てきます。Action に至っては A / B とか Not / A とかおいおーい！って感じの選択を迫られるわけです。
タグは２つのフラグを持っています。１つは Inventoriedフラグと呼ばれるもので、AまたはBの状態を持ちます。もう１つは SLフラグと呼ばれるもので、セットまたはリセットの状態を持ちます。
この２つのフラグ、動作的にはすごく似ていて同じでもいいんじゃないかという気もしますがいちおう分かれているようです。
リーダがタグを読み取るとき、SDKとかでは Inventory コマンド一発とかで読取りしますが、実際は Select コマンドを投げてから読取りをしています。この Select コマンドのときに上のフラグを操作して、読取りの際に特定のフラグのものだけ読み取るという動作になっています。
Inventoriedフラグはインベントリのときに利用して、SLフラグをマスクの用途で利用するという棲み分けになっているようです。
そんなわけでマスクの動作とは簡単に言うと、Select で対象のタグの SLフラグをセットの状態にする→インベントリで SLフラグがセットされたものだけを読み取るという流れになります。
じゃぁこの Action は何なんだということになるわけですが、Selectコマンド時に各タグが自分のフラグをどう変更するかの指示になってます。まず / で左と右に別れますが、これは左が「マスクにヒットするタグ」で右が「マスクにヒットしないタグ」の動作になります。Aは Inventoriedフラグだったら A にして、SLフラグだったらセットにします（Inventoried と SL のどっちを変えるかは一番上の Target で指定します）。Bは Inventoriedフラグは B にして SLフラグはリセットにします。Not は何もしない、Negate はフラグを反転します。
通常は A / B でいいと思いますが、他の設定がどんな使い方を想定しているのか大変気になるところでもあります。
マスクなので SLフラグだけ変えればいいと思うのですが、Inventoriedフラグも変えることができるのでこれはいったい何に使うのかという妄想が膨らみますねー。謎です。
棚卸パッケージをOneDriveの設定されたPCにインストールして使おうとしたところ、問題が起こったので、調べてみました。
