Amazon Fire HD 10で、MANICAモバイルは動くのか。

こんにちは、久しぶりのBlog投稿です。

今回は、Amazon Fire HD 10でMANICAモバイルは動くのか、というお題となります。

Amazon Fire シリーズといえば、Amazonプライム会員だと何かと便利で、（残念ながらGooglePlayStoreは使えないけど）大変コスパに優れた端末として有名かと思います。

我が家でも昨年の子どもの誕生日にプレゼントしてたりしますが、10インチの大きさで1.5万円程度と破格なうえに、画面の質感とかパフォーマンスあどなど何ら問題なく利用できています。ちなみに、頻繁にセールが行わている機種でもあるので、急がなければ1万円程度での購入も可能ですね。

こんなオトクな機種で、はたして弊社のMANICAモバイルを使用することができるのでしょうか。

MANICAモバイルはRFIDハンディリーダーとの組み合わせで使うのが基本なので、ハンディリーダーにアタッチするニュアンスだとタブレットよりはスマートフォン向けのアプリではあるのですが、Webブラウザで管理画面を確認するという観点ではタブレットのほうが使いやすかったりしますかね。

さて、結論からいうと問題なくお使いいただけるわけですが、apkを直接インストールするため少しだけ設定変更など必要です。

Fire HDをPCとUSB接続してゴニョゴニョできるような方であれば、説明の必要もないかと思いますがもう少し手軽にMANICAモバイルのapkファイルのダウンロードリンク（URL）を、Webブラウザ（デフォルトはSilkブラウザ）からログインしたGmailのアカウントで受け取って、そこからダウンロードみたいな場合、Silkブラウザからダウンロードしたapkファイルのインストールを実行できるように権限の設定を変更します。

まずは設定メニューから、セキュリティとプライバシーを選択します。

次に、不明ソースからのアプリを選択、

ここで、このアプリ提供元を許可、にチェックを入れるだけです。

という感じで、とっても簡単です。インストールして起動すると、いつものMANICAモバイルのメニューです。探索と棚卸しのメニューが画面サイズにあってないですが、使用上の問題はなさそうです。

Silkブラウザで管理画面にアクセスすると、こんな感じで見やすいです。

素敵ですね！

塗料のシールド効果を実験してみた

Amazonなどで、容易に入手できる塗料で、電波のシールド効果を実験してみました。

使用したリーダーとタグ

・BHT-1281QULWB-CE

・ALN-9654（Gタグ）

塗装した容器内にタグを入れ、リーダーのMANICA EXCEL TOOL で電波を最小の出力にして、読み取りの実験を行いました。

ネット検索すると、電磁波シールド効果のある塗料として導電塗料が出てくるのですが、導電塗料以外で、気になる塗料があったので、まずはその塗料で試してみました。

マグネットペイント（ターナー色彩株式会社）Amazon価格：2,090円（税込）

この塗料は、塗るだけで磁石がくっつく下地用塗料です。例えば、チョークボードペイントを上塗りすると、板や室内の壁などにオリジナルの黒板を作成ることができます。

成分には「顔料」としか記載されていませんが、磁石がくっつくという事なので金属性の成分を含んでいると思われます。また、導電塗料では塗れないような材質に塗装できます。

木に塗装できるとのことなので、以下のような、木箱の内側に塗り、タグを中に入れて実験しました。

この塗料は３回重ね塗りするのですが、１回塗る都度に読み取りしてみました。読み取り距離は以下のように変化しました。

未塗装　：　65cm

１回目　：　50cm

２回目　：　35cm

３回目　：　30cm

塗り重ねていくと、読み取りは悪くなっていくのですが、シールドとして使用するのは無理でした。

ちなみに、磁石はくっつきました。

次に、導電塗料で実験しました。

導電塗料は、電流が流れやすいカーボンや金属の粉末を溶かした塗料です。金属が含まれている事から電磁波シールドとしても使用できます。

使用した導電塗料は以下の３種類で、いずれもプラスコート株式会社の「ポリカーム（Polycalm）」という商品のスプレー缶（300ml）になります。

それぞれの塗料の導電性物質と価格は、写真右から以下のとおりです。

①カーボングラファイト　Amazon価格：1,870円（税込）

②ニッケル　Amazon価格：4,290円（税込）

③銀・銅　Amazon価格：4,620円（税込）

以下のような、材質がポリプロピレン（PP）の容器の外側に塗り、タグを中に入れて実験しました。（写真は銀銅の塗料で塗装）

なお、塗装に慣れてないのため、側面は塗りムラができるなど、うまく塗れなかったので、平で綺麗に塗装できたフタ側より読み取りました。

①カーボングラファイト

この塗料は、発泡スチロールの静電気対策用との事なので、発泡スチロールには直接塗れますが、実験で使用する容器はPPなので、プラスチック用のプライマーを下塗りしてから塗装しました。

読み取り距離は 0 cmでした。フタにリーダーを押し付けるようにしても読み取りませんでした。

しかし、出力を最小から１つ上げると、7 cm の距離で読み取りました。

高いシールド効果を必要としない用途であれば使用できるかもしれません。

②ニッケル

読み取り距離は 0 cmで、出力を最大にしても読み取れませんでした。

なお、抵抗値が小さいほど電磁波シールド性が高くなるとの事で、カーボンよりも効果がありました。

ただし、直接、容器に塗装したのですが、実験後にクラックが発生し、塗装が剥がれてしまいました。カーボンの実験のようにプライマーを下塗りすれば大丈夫かもしれませんが、塗装に関して不安を感じました。

③銀・銅

PPへの塗装は△ですが、直接、容器に塗装しました。

ニッケルと同様、読み取り距離は 0 cmで、出力を最大にしても読み取れませんでした。

塗装に関しては、ニッケルのように剥がれる事はありませんでした。

導電塗料が電磁波シールドの効果があるとの事ですが、実際に試してみると、導電性物質による効果の違いや、塗装の問題点も体感できました。

考察

３つの製品のシールド効果の実験結果は、

銀・銅　≒　ニッケル　＞　カーボングラファイト

でした。

カーボングラファイトはシールド効果が劣りますが、銀・銅とニッケルは十分な効果がりました。

また、ニッケルの抵抗値は約１Ωで、銀・銅は１Ω以下となっているので、銀・銅の方がシールド性が高いのかもしれません。

価格はカーボンが一番安く、半額以下なのですが、メーカー提示の塗布面積では他の２製品はスプレー缶１本で1㎡なのに対し、カーボンは1/4の0.25㎡（50cm×50cm）しか塗れません。

また、ニッケルより銀・銅の方が少し価格が高いですが、塗装の事を考えると、今回試した３製品の中では、銀・銅の塗料が１番お勧めです。

ちなみに、銀・銅の塗料は、１kg入りの缶も販売されており、Amazonで 20,162円（税込）です。

導電塗料の活用について

以前、周囲のタグを読み取らないよう、スチール製の郵便ポストや引出しの中にテーブルスキャナを取り付け、中に入れたタグのみを読み取るような工作物を作った事があります。電源ケーブルを通すための隙間や、その他の隙間などにアルミ箔やアルミテープを貼るなどしたのですが、耐久性の問題もあり、電波漏れを防ぐことに苦労しました。

導電塗料により、プラスチック製品なども使用できるようになるので、選択肢も広がります。また、プラスチック製品であれば、必要に応じて加工する事も可能と思います。

また、飛沫防止のアクリル製パーテーションに塗って、隣の作業机のタグ読み取りを防ぐなどの利用も考えられます。ただし、金属と同様、電波を反射するので、設置場所に注意が必要です。

第23回 自動認識総合展に出展します。

昨年はコロナの影響で残念ながら中止となってしまった自動認識展ですが、
今年は無事に開催とのことで弊社も2年ぶりの出展となります。

例年通り、こじんまりとしたブースにゴチャゴチャ、っと色々ならべる感じになるかと思います。

そういえば前回は、何故かプレミアムのついたスニーカーを展示して、
いろいろあってテレビの取材でも取り上げていただいたのでした。

https://youtu.be/35llff7Xogc?t=246

今回は謎のブロックが並ぶ予定です、果たしてどんな仕掛けなのか。

ぜひ現地でご体感ください。

自動認識総合展は、10月の6〜8日まで東京ビッグサイトの南館で開催されます。
https://www.autoid-expo.com/tokyo/

気を測る

 センサーを搭載した RFID タグはそれなりに登場してきているんですが、その中の一つに farsens のタグがあります。

このタグはIOが付いていて、そこに別途センサーを接続することで測定ができるという面白い使い方ができます。仕様を見るとここに繋いだセンサーの抵抗値を値として取得できるようです。

タグのユーザ領域にデータが保存されますので、専用のリーダは必要なくどんなUHFのリーダでも読み取ることができるのもこのタグの特長になってます。

最近エクセルツールに対応した Apulsetech のリーダで試してみます。

エクセルツールをちょっと改良して、タグの値を取得できるようにしてみました。

まずは何も繋げずに測定してみます。

１億７千万くらいの値になりました。単位はオームだそうです。

次にショートさせてみます。

３０オームくらいになりました。

次は両端を手で握って図ってみます。

私の抵抗は４０万オームくらいらしいです（笑

さらにこんなの用意しました。板にアルミホイルを巻いただけのプレートです。昔なんかの付録だったかでこういう板と紙コップみたいなのと何か銅線を繋いで気を測るみたいなのがあったと思うんですがありませんでした？そういうの？そうですか。

このまま測ると１３と低い値が出ています。

ここで気を送ってみます。はぁぁー　っと。さぁ値は変わるのか？

気のせいだな。きっと。

RTKを使った位置測定を試す

 とある案件で RTK を使った位置測定のデバイスを作成したんですが、これがいろいろ使えるということで今回は納品した器材をお借りして実際に測定をやってみました。

ちなみに RTK は GPS のごっついみたいな感じで、ｃｍ単位で位置の測定ができるというスグレモノです。ドローンの位置制御みたいなのに使われてます。

こちらがデバイスになります。

右から通信用親機、基準局、移動局にあたる子機の３種類です。親機は AC電源＋Wifi が必要ですがその他の機器はバッテリーで動作します。

こちらのデバイスは各デバイスの通信として LoRa を使用している所が大きな特長になります。通常の RTK では、基準局のデータをリアルタイムに移動局に渡して移動局が位置の計算を行います。この方法では基準局のデータを移動局に渡すため、基準局と移動局が通信できる必要があります。この通信はWifiを利用していることが多く、測定位置がWifiの通信範囲に縛られます。

今回のデバイスは基準局のデータを移動局に渡さず、すべてのデータをクラウドに集めて計算するようになっていますので、各機器は通信用の親機にデータを投げればよく、この通信に LoRa を使用しているため、数キロ離れた場所でも測定が可能になります。

数キロ離れた測定は検証が大変なので近い距離で試してみます。

駐車場に設置。親機は Wifi でインターネットに接続する必要があるので向こうにある建物に設置してあります。

結構なデータ量を LoRa で送らないといけないんですが LoRa は通信に時間がかかる上、複数の機器が（チャンネルが同じ場合）同時に通信できないので、PPS を使って正確な時刻計測を行い、送信時間を各機器が分割することで各機器の送信が被らないように各機器が制御を行っています。

電源をONして５分程度すると、だいたい位置がFIXしてきます。

こちらがクラウド側の結果表示画面です。写真の奥側からこっちを見てる感じなのでちょっとわかりづらくて申し訳ありません。が、だいたい位置関係は合ってるようです。右側に X,Y,Z の値が出てますが、単位は ｍ です。X が東西方向、Y が南北方向、Z が高さ方向です。

これから計算すると、子機１と子機２の距離は５．４６ｍだそうですので検証してみましょう。

子機１にメジャーを合わせて

子機２までの距離を測ってみるとほら！５．４６ｍに近い！すげーぜ RTK

RFID的商品マスタの持ち方を考えてみた

RFIDを使って在庫管理をしようと思ったとき、在庫データの持たせ方は大きく2つに分類されると考えています。すなわち、

• ユニークなタグIDに品番や品名などの商品の情報を紐づけて管理する方法
• システムに商品マスタを持ち、タグIDの一部を使って商品マスタとマッチングして管理する方法

前者は、たとえばMANICAモバイルや棚卸パッケージで採用している方法です。今回は後者の方法について考えてみたいと思います。

標準的な方法（SGTIN-96）

RFIDを使って商品の在庫管理を行う場合、JANコードベースのSGTIN-96を使った方法が一つ考えられます。このとき商品マスタはこんな感じになっていると思います。

商品マスタ（商品コード, 商品名, JANコード, 仕様, ...）

ICタグを読んで商品コード、商品名やそのほか仕様等を取得する場合は、下記のような変換を行う感じになると思います。

SGTIN-96　→　JANコード　→　JANコードで商品マスタを検索　→　商品コードなどを取得

標準的でない方法（独自コード）

さまざまな理由で独自コードを採用するケースも考えられます。このとき商品マスタはこんな感じになっていると思います。

商品マスタ（商品コード, 商品名, バーコード, 仕様, ...）

標準的な方法のJANコードがバーコードに変わっただけですね。もしかすると、商品コードとバーコードが一致しているかもしれません。標準的な方法と同じように商品コード、商品名やそのほか仕様等を取得する場合を考えてみます。ICタグのEPCのなかに商品コードが含まれているとします。

EPC　→　商品コード　→　商品コードで商品マスタを検索　→　商品コードなどを取得

標準的な方法とほとんど変わらないですね。ただ、独自コードですので、EPCから商品コードへの変換は独自コードごとに対応（＝カスタマイズ）が必要となります。

統一した方法（SGTIN-96、独自コード）

SGTIN-96も独自コードも統一して管理できる方法を考えてみます。まず、商品マスタはこんな形で持たせてみます。

商品マスタ（商品コード, 商品名, バーコード, 検索キー, 仕様, ...）

ここで新たに追加した検索キーには、シリアルを0として当該商品コードをEPCにエンコードした場合の値を保持しておきます。他にMaskをシステムで一つ保持しておきます。Maskはシステムで採用したタグID長のByte配列とし、EPCのうち商品コードを特定するための部分に1を立てておきます。EPCから商品コードを取得するにはこんな感じになると思います。

EPC　→　検索キー（EPCとMaskをAnd）　→　検索キーで商品マスタを検索　→　商品コードなどを取得

SGTIN-96、JANコードが4573228900149の場合はこんな感じになると思います。

Mask: FFFF FFFF FFFF FFC0 0000 0000

商品マスタ（商品コード1, 商品名1, 4573228900149, 302DB42318A0038000000000, 仕様1, ...)

たとえば、EPC: 302DB42318A0038000001231 を読み取ったら、Maskして、302DB42318A0038000000000 となるので、商品マスタを検索して、商品コード1などが取得できます。

一方で、独自コードの場合はこんな感じになると思います。タグIDの0～15 bit目と32～47 bit目に分かれて、商品コード相当の値が入っていたとします。

Mask: FFFF 0000 FFFF 0000 0000 0000

商品マスタ（商品コード2, 商品名2, A123B456, A1230000B456000000000000, 仕様2, ...)

たとえば、EPC: A1230000B456000000004567 を読み取ったら、MaskしてA1230000B456000000000000 となるので、商品コード2などが取得できます。

あと考える必要があるのは商品マスタの連携方法だと思います。当然検索キーに相当する列は存在しないので、連携の際にエンコードルールに基づいて変換して登録することになると思います。

商品マスタ連携部分は都度対応が求められる箇所かと思いますので、そこに修正を押し込められるのはこの持ち方のメリットかなと思います。こんなケースはどうするのか、など考慮不足などあれば、コメントでお知らせください。

DRAGINO の LoRaWAN ゲートウェイと Azure IoT Hub を接続する

 最近 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 というまさしくそれな的なのがあるので選んで保存します。

次にMQTTの設定です。Azure IoT Hub にMQTTで接続するには、SASと呼ばれるセキュリティトークンを使用する方法と、X.509証明書を利用する方法があるようです。

https://www.dragino.com/downloads/downloads/LoRa_Gateway/LPS8/Firmware/Application_Note/MQTT_WebUserInterface-v0.3.pdf

この辺のマニュアルを読んでみると、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を利用する前提のようです。

ということで MQTT Server Profile を General に変更します。

ファイルは画面の設定のように選択しますが、User IDのところは {IoT hub name}.azure-devices.net/{device id} を設定します。

ここまでで設定は完璧です。完璧なんですが…

飛ばない…　データ…　いくら送っても…　Azureまで飛んでこない…　あう・・・

何で？特にエラー出るわけでもなく Azure のログにも大した情報は出ていない。ダメか、詰んだか。そういえば上のマニュアルで mqtt のサンプルコマンドが載ってたな。そうか、それを試すのだ。

ゲートウェイに SSH で接続して、コマンドで MQTT 送信してみます。

mosquitto_pub -d -h XXXX.azure-devices.net 

      -p 8883 -u XXXX.azure-devices.net/H0001 

      --cafile /etc/iot/cert/Azure.cer 

      --cert /etc/iot/cert/new-device.cert.pem 

      --key /etc/iot/cert/new-device.key.pem 

      -i H0001 

      -t devices/H0001/messages/events/ 

      -m "{ Hello }"

するとあれ？飛ぶぞ？えっ？えっ？

何が起きてるんだろう（まぁ、こんなことはよくあるけど）。マニュアルでは MQTT の処理は mqtt_process.sh がやってるとか書いてあった。じゃ何やってるかちょっと覗いてみるか。送信部分を抜粋。

# ------------------------------------------
# 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
  

設定で処理が別れている様子。ログを見ると General の設定は case 2 にあたるようだ。よくみるとあれ？ User IDの設定(-u)が無い！　あー、それでかー、そんなことかー、ようやく原因がわかったー。おもむろに -u の設定を追加して保存。

これでようやく無事に送信はできるようになりました。

※注意　今回はアップリンクの話だけで、ダウンリンクはまだこれから試します。