せっかくなのでUIFLOWを使う設定を行ってみる

M5StackのホームページからUIFlowを選択する。
https://docs.m5stack.com/#/en/core/core2
Burning toolをインストール。IDEと同時にできないのはしょうがない。。。
Zip形式がダウンロードされるので、解凍してM5Burner.exeを実行。
すると、M5Burnerが起動され、UIFLOW(CORE2)なるものができてきたので、これを実行。
よく見るとゲームみたいなものもある。。。 まぁ。 これは後でのお楽しみ(^^;
COMポートを合わせこみ、Downloadボタンを押すとBurnボタンも出てきたので押す!
ん? Wifi Setting? USB経由ではないのか? まぁ。いいや。 何とでもなる。
押したら、ダウンロード始まった。 あれ? CORE2にはWifi設定していないぞ?
あぁ。 ダウンロードイメージにWifi情報を組み込んだということか。
なるほど。 無事にBurn終了。 CORE2の画面も変わった。

次のAPIKEYでのペアリング。
CORE2でUIFLOWを選択するとUSBかWi-Fiの選択が出てくるのでWi-Fiを選択。
API KEYが出てきた。 これをメモメモ
今度は下記にアクセスすると、
https://flow.m5stack.com/
Api Key、言語、デバイス対応(CORE2を選択)、テーマ色、を聞いてくる。
M5BunerでWindowsを選ぶとそちらに飛ぼうとしたので、そこはキャンセルし。
まずはOkを押させてもらう。
お。 接続した。 スクラッチに近い感触の絵が出てきたが、デモもある。
これはわかりやすくて最初のとっかかりにはよさそうだ。
ふむ。 どちらかというとWebをエンジニアリングツールとして使うだけであり、CORE2とはWi-fi経由で行うということみたいであり、特にInternet経由というわけではなさそうだ。






IDEの設定とM5Stack Core2の工場出荷 への戻し方確認

ここでは、基本として覚えておきたい部分のメモ
(このページでは保証できないので、各自の責任において実施してください。)

M5StackのHomePage
https://docs.m5stack.com/#/
上記からCORE2をクリックする。 チュートリアル、機器仕様、ピンアサインなどなど

工場出荷のソフトに戻す方法
1.上記URLからEASYLOADERを選択し、WINDOWSを選択。
インストーラがダウンロードされるので、セキュリティを気にしつつ実行!
Comポートを選んで Burn ボタンを押す。

2.Arduino IDEの設定方法
私の使っているIDEは1.8.13ということを前提に置いておいて。
先のM5StackのHomePageからQUICK-STARTを選択しArduino IDEを選択。
ここで、ボードマネージャに指定するURLをコピーペースとしておく。
IDEのファイルメニューー>環境設定から
追加のボードマネージャに先ほど指定したURLをペースト。
ただし、すでに追加されている場合は、右のボタンを押してURLを追加する。
念のためIDEを再起動し、ツールメニューのボードのボードマネージャを選択。
ここでInternetから情報を集めてきているはずなので、少し待ってから検索バーのようなところにM5Stackと入力すると、インストールできる状態になる。 ここで何も出てこなかったらネットワーク接続や、先ほど設定したURLを疑うのが妥当。
インストールが完了したらダイアログを閉じて、再度ツールメニューのボードマネージャから
M5Stack ArduinoからM5Stack-Core2を選択。
次にライブラリとしてスケッチメニューからライブラリをインクルードのライブラリマネージャを選択しM5Core2で検索。
私の場合、M5Core2とESP32-Chimera-Coreが出てきたがM5Core2のみインストールした。

動作確認としてスケッチ例でM5StackCore2のTouchを選択してダウンロード。
無事にダウントードが終了し、タッチをするとしたところが白くなることを確認できた。

試しに ここでOFF/ON。 OFFは電源ボタンを3-4秒押し続けてリセットボタン横のLEDが消えることを確認。
再度ここでON。 画面変化がなく寂しいがタッチすると白くなることを確認。

本題はここから、ここでEASYLOADRをつかってBURNしてみる。

おぉぉ 買った状態に戻った。 これで一安心!







M5Stack Core2

また、増えてしまった。 M5Stackとしてはまだ2個目。 でもたぶんこの部屋には動かなくなったものも含めESP32は10台以上。。。 Beagle Boneから始まってあちこちに手を出してしまった気もする。 それはさておき、進化の激しさをかじる。digital divideの解消にも一役買えそうである。

さて、送られてきたM5Stack Core2の口開け式も無事終了。 特に輸送などの問題はなさそう。
さっそく電源ボタンみたいなものを押してみると、おぉ。 なんかいっぱい文字が、、、表示があるって新鮮。 SDCard Find failed ん? そりゃそうだ。 CLass10のが一枚余っているのだが、まぁ あとで考えるか。 Touch to Skipふむふむ とりあえず画面をタッチ。

おぉ こんな絵が出てきた。

ご立派。 SOUNDのFFTもついてる! ふーむ 初期インストールソフトができすぎ!

もったいないので、元に戻す方法はきちんと押さえておこう。

サンプルプログラム公開

GPS・QZSSロボットカーコンテスト2020で使用した測位とWaypoint算出に関するソースコードを参考用にUpします。
本ソースコードは「測位航法学会特製 F9P搭載受信機」にも対応しているはずです。

最適ではないのですが、参考になる方もいるかと思い公開に踏み切りました。 もちろん無保証なのと、これによる問題障害については一切責任は負えないので、そのあたりを理解してみてもらえば幸いです。 また、本業が忙しく、コメント・質問などに、答えられない場合があります。


2019年大会はFix率が悪く、走行テストが難航し2回目の走行をキャンセルせざるを得なかったのですが、今年は参考までに以下の対策を講じてみた。 (どれが効果的かというのは感触です。)

-F9PのFarmwareのUpgrade
これはかなり効果があったと思います。
-QZSSの無効化
これも効果があったように感じますが、FarmのUpdate後にL1Sに関する記事を読みL1Sを無効化して再登録。 Fix率は下がらないことを確認した。 L1Sの無効化が聞いたのかFarmware Updateが効いたのかは不明。
-アンテナ背面の銅箔テープによるマルチパス防止
これは気持ちの問題だった気がする。
-ntrip Serverとのアクセス手法
これは効果大だった。制御周期も早いので、制御の合間に数文字程度を読み取って制御側の処理をやっていたが、メッセージ終了までは制御は行わず一気に処理を行った。
-F9P更新周期
F9Pはカタログスペック上20Hzとなっており、51ms(50msが定義できなかった)で動作させた。Logを見るとデータが変更しないときもあるが、最速で見るれ可能性が高いと想定し使ったが、Fixしたのは1-2度のみですぐに設定を戻した。(100mS~300ms)

そのほか2019年では悩んでいたBluetooth通信であったが、ESP32 DevkitをV4にすることで同じソースコードで動作した。試しにV2に戻すと動作しない。 昨年はこれでだいぶん時間を食ってしまったが。 ただ、PC側は毎回削除し、登録している。 この辺はかなり改善の余地がある。 また、Bluetoothを使っていると、たまに処理が止まったり遅くなったりすることがある。情報取得時以外はPC側から接続しないで使っていた。

—–
本ソースコードは無保証の条件で、無償提供し、個人・商用を問わず利用は自由です。ただし、内部で使用されているライブラリなどは、そのライセンス条項に従ってください。

Sample.zip

—–

実際の土壌の湿度と地温の測定

本来の目的であった、地中の水分(土壌湿度)と地温の測定を行う。

使用したセンサーは(購入先は違うが)
DS18B20 防水型センサ
https://www.robotshop.com/jp/ja/ds18b20-waterproof-digital-temperature-sensor.html
土壌湿度センサ
https://www.amazon.co.jp/gp/product/B07K1DP211/ref=ppx_yo_dt_b_asin_title_o02_s01?ie=UTF8&psc=1

これらをDS18B20はOneWireで通信するために以下のライブラリをインストールした。
https://github.com/PaulStoffregen/OneWire
https://github.com/milesburton/Arduino-Temperature-Control-Library

配線としては両方のセンサとも3.3VとGNDに配線した後に、
温度計はD3を使用
土壌計はA1を使用
した。

温度は温度の値がそのまま出るが、湿度は出てくる電圧をanalogReadのレンジに対しての%に修正した。
今回は、モバイルバッテリを使って、連続動作時間や変化を知るためにブレッドボードで配線し、配線部にはホットボンドで仮止め、そして全体をビニール袋で覆った。

モバイルバッテリと合わせたところ

ビニール袋に入れたところ

地面に刺したところ

これで、受信できていることを確認した。
これによって、例えば数100mはなれた畑から自宅にLPWANで接続して地温や水分状態を監視できるプロトタイプが出来上がった。

ちなみにArduinoのソースの改造部分は下記となる。
( ” /// Modify” 部分を追加”)

定義部分への追加

// for Temperatures Sensor and Moisture Sensors  /// Modify
#include <OneWire.h>             /// Modify
#include <DallasTemperature.h>   /// Modify

#define dht_dpin A0 // Use A0 pin as Data pin for DHT11. 
#define DHTTYPE DHT11   // DHT 11 

// for Temperatures Sensor and Moisture Sensors   /// Modify
#define ONE_WIRE_BUS 3 // データ(黄)で使用するポート番号  /// Modify
#define SENSER_BIT    9      // 精度の設定bit     /// Modify
OneWire oneWire(ONE_WIRE_BUS);                    /// Modify
DallasTemperature sensors(&oneWire);              /// Modify

“void do_send(osjob_t* j){ “の中

// for Temperatures Sensor and Moisture Sensors    /// Modify
    sensors.requestTemperatures();              // 温度取得要求 /// Modify
    float Mo01,Ti01;                               /// Modify
    Mo01 = 100.0 - (((float) analogRead(1) + 1.0) / 1024.0 * 100.0 );  /// Modify
    Ti01 = (float) sensors.getTempCByIndex(0);     /// Modify
    Serial.print("Soil temp =");                   /// Modify
    Serial.println(Ti01); //温度の取得&シリアル送信  /// Modify
    Serial.print("Moisture =");                     /// Modify
    Serial.println(Mo01); //土壌湿度のシリアル送信  /// Modify

    CayenneLPP lpp(51);                    // create a buffer of 51 bytes to store the payload

    lpp.reset();                           // clear the buffer
//    lpp.addTemperature(1, t);       // on channel 1, add temperature, value 22.5°C   /// Modify
//    lpp.addRelativeHumidity(2, h);  // on channel 2, Hudimidity   /// Modify
    lpp.addTemperature(1, Ti01);      // on channel 1, add temperature, value 22.5°C   /// Modify
    lpp.addRelativeHumidity(2, Mo01); // on channel 2, Hudimidity   /// Modify

以上

HATについているGPSについて

このLoRa WAN GatewayにはGPSが搭載されている。このホームページでGPSについてを記載しておく。

日本での主な入手元の一つであるRSコンポーネンツでの仕様は、結構さみしい。
ほとんどがLoRa WANのテスト用で使っているためと思われる。
***************************
https://jp.rs-online.com/web/p/products/1875121
とくにデータシートはなく、記載として下記の通り
DGPS 、 SBA をサポート( WAAS/EGNOS / MSAS / GAGAN )
内部パッチアンテナと外部アクティブアンテナの GPS 自動切り替え
PPS 対NMEA は、タイムサービスで使用できます
SDK コマンドをサポートします
内蔵LNAによって感度を最適化
EASY™は外部メモリを使わない先進のAGPS技術
AlwaysLocate™は周期モードのインテリジェントコントローラ
GPS FLP モードでは、通常モードの消費電力が約 50 % です
短絡保護及びアンテナ検出をサポート
**********************
ただ、もう少し見てみると、
GPSモジュールの写真を見ると、

ここでQUECELのWebで確認して特徴的な項目を挙げると。
https://www.quectel.com/UploadFile/Product/Quectel_L89_GNSS_Specification_V1.1.pdf
*L1信号だけでなくL5信号も受信!
昨年のGPSロボットカーではL1/L2の二周波受信を行った。これはL2はないものの、最近の日本の衛星である”みちびき”には対応。 ここ10年くらいの設計。
ただ、L2がないのは残念だが、この価格では仕方ない。
*RTCMには未対応らしく、RTKという単語も見当たらない。 これはちょっとマイナスポイント。 RTCMを利用して1-2cm位置測定という目的には使えない。みちびき信号で頑張るか。
*データ更新周期1秒。 (0.1秒は開発中)
歩行や通常のトラッキングには何も問題ないのだが、GPSロボットカーに使うにしてはちょっと役不足か。。。

参考になれば。

屋外からの接続結果

試しに部屋の机の上に無造作に置いて、どこまで受信できるかを見てみた。
環境の悪い状態でテストした例である。
時期にチャンピョンデータも取得したいと思っている。
先に断っておくが、この辺りの専門家というわけではないので、出てくる数字の目安というものがわからない。また、名称についても、これまでの経験上から想像しているものが多く、LPWANに適応していないものも多く、そもそも間違って覚えているものも多いと思われるので、そこはご容赦願いたい。

まず、直線距離は約500m。これ以上はなれると受信できなくなったので、受信限界時のRSSIとSNRに注目。

用語として
RSSIとは受信信号強度(Received Signal Strength Indicator)であるが、単位が明確についている絶対値ではない。チップメーカで決められた値のため比較はできない。同じ構造を持つ機器での比較や移動時の比較には良い。
SNRとは信号対雑音比(Signal-to-Noise Ratio)であり、信号とノイズの強度差分である。 ノイズが大きくなれば信号は聞き取りにくくなる。小さい電力で少ないデータを使うことを前提に、信号とノイズの差分をどれだけ少なくても通信を確立させるかというところに醍醐味がある。

RSSIから見ていくとする。 1mと500mでの比較を行う。

1mでは大体-41から-45を示しているが、500mでは-107を示した。それ以下の数値の時は通信できなかった。単位としてdBmで表示されているもののMQTTのプロトコルの特性としてデータの種類の定義で単位が固定されてしまうので、ここは信じないほうが良い可能性がある。 これからほかの人の報告を見ながら考えていく。
ここでは、数値が-90程度までは使える。
(そのうち距離のトレンドも取ってみたい。)
また、気になったのが朝8時前は受信強度が安定していたことである。数値が動いているので、正しくデータを読み取っているのだが、ちょうどこの時間はいくつかのPCに電源が入ったころである。屋内の影響とは限らないが、’I’との戦いはここに始まったことではないので、将来のネタとして残しておきたい。

SNRの比較である。

1mでは大体10から12dbを示している。これ自体はLPWAN自体がノイズと信号比率がそれほど大きくなくても大丈夫なものとして考えていたが、500mでは-17dbを観測しつつも連続受信をしていた。 マイナス? どれほど信号を抜き出せるのか? と思いながら、この値は正常なものかどうか考えあぐねている。

どちらにせよ、この両者の数値を見て経験を積んでいくこととなりそうである。

********************************番外1*****
番外としてこのLoRa GatewayのSpecの一部は下記であり、さらに初感を付しておく。
*168 dB maximum link budget.
Link Budjetは損失と通信距離の関係である、この数値でシミュレータにかけると
理論上の到達距離を算出できるのだが、値の指標がわからない。
LPWANは長距離とうたっている関係上良い数値なのでは?

*+20 dBm – 100 mW constant RF output vs.
これは、ただ単に空中線電力の 100mWとみてよいのか?
(内部レジスタで設定できるようなので、実際の出力は不明)

*Programmable bit rate up to 300 kbps.
LPWAは遅いというイメージがあったので、この数値であれば結構使える。
実力を測りたいところだが、プロトコル上簡単に実測するのは難しそう。

*High sensitivity: down to -148 dBm.
さすがLPWAN用ともいうべきか、GPS受信機並みの受信感度といったところか

*FSK, GFSK, MSK, GMSK, LoRaTM and OOK modulation.
こんなにたくさんの変調方式をサポートしている? これが普通?

*127 dB Dynamic Range RSSI.
受信感度が高いためかダイナミックレンジも大きい。

*Packet engine up to 256 bytes with CRC
LoRa WAN使用をフルサポートとみてよいと信じる。

*Built-in temperature sensor and low battery indicator.
LEDが見つけられない。。。。

Cayenneとの接続

ここでは、デバイス(センサ)からCayenneを経由してデータを見るところまでを確認する。すでに、上記のProject Dまでは確認が終わっているのでTTNとCayenneの接続確認となる。 今回はCayenneに乗せるつもりでこれまで準備してきたのでちょっとずるい感もあるが、まずは完結させることが大事として進めていく。

まずCayenneとはIoTサービスを展開するMyDevicesの機能(サービス?)の一つである。TTNなどにUpされたデータや直接センサからのデータを受けて、データの表示やトレンド、メータ表示などを実施してくれる。 これも無料で使用できるが、メールアドレスの登録が必要である。

連携としてはCayenne側でTTNに登録したデバイスEUIを登録することで、Cayenne側で新たしいURL(ダッシュボード)が自動生成される。
このURL部分をTTN側に連携させてつながりが行われる。

MyDevicesのCayenne側での設定として下記を開いて”SIGN UP FREE”で登録する。
https://developers.mydevices.com/cayenne/features/

これから作るものはCyenneの中ではProjectと呼ばれるものである。
まだわからない部分も多いが、ダッシュボードにデバイスをどんどん登録していき、それをProjectという枠にデバイスのパラメータを割り付ける感じである。ここでは、ダッシュボードへデバイスを登録する部分を実施する。

Cayenneで最初の選択があるのは追加するDeviceがどこから来るのかという感じである。今回はLoRaを選択する。 

すると、LoRaのBroker一覧が出てくるので、そこでTTNを選択する。

このあと、いろんなセンサが出てくるが、ここでは”Cayenne LPP”を選択する。

ここで、詳細を入力する。
ここで出てくる名称にはデバイスの名前を入れるようにしている。
そのほかTTNで指定しているデバイスEUIを入れる。 そのあとセンサを設置している位置(住所)を入力して”Add Device”を押す。
コンフリクトのエラーが出た場合は、大体デバイスEUIに不整合があるケースであった。
ここでダッシュボードが出来上がるが、ここのURLがTTNと接続するためのキーとなる。

このあとは、このキーをTTNに割り付けるためにTTNでの操作を行う。
まず、データのフォーマットの指定としてPayload Formatで”Cayenne LPP”を指定する。

次にその右の”インテグレーション”ボタンを押し、MyDevicesと上記で控えたキーを入力する。
その前に、”インテグレーション”を押した後、連携先のMyDevicesを選択する。

その後、控えたURLの一部を”プロセスID”に入力し、”Access Key”に”default Key”を選択する。

その後下にある”インテグレーションの追加”でインテグレーションを指定する。
設定が正しければ、TTNとCayenneが連携されてCayenn側でデータが表示されるはずである。
(私はTry&Errorで横道それながら覚えていくタイプなので、すぐに表示でなくてもあせらずにゆっくり手順を確認する。 ほかのWebを参考にしながら)

データがうまく連携されていない場合は、センサ一の地図だけが出てしまう。
その場合は、センサから順にどこにデータが来ているかをみてみるとよい。

デバイスの立ち上げとTTNでの確認

ここでは、下記のCとDの部分の確認をする

ここではLoRa用のチップの乗ったArduino Uno相当である(DRAGINO LoRa Mini)を用いた。

これはArduino IDEを用いて開発することになるが必要なライブラリやサンプルを入手する。

•arduino-lmic-master-for-LG01-JP-REL20190308.zip
LMiCというのはIBMがLoRaを使用するために作成したライブラリである。これを改訂したものが上記である。ただし、上記はまだ日本版に対応していないので日本の周波数向けの定義を少し加えないとならない。 このLimicライブラリのlorabase_as923.hのなかで使用する周波数を手動で変更し定義している。

•DHT_sensor_library.zip
このモジュールはDHT11を使用するためのライブラリである。

•CayenneLPP.zip
ここで入手したデータはCayenneで利用するために、このライブラリを利用している。

その他、Adafruit Unified Sensorをライブラリの管理から追加している。このPCにはいくつかのライブラリが含まれているので、ライブラリの管理に表れてきたが落とし穴になる可能性がある。

•Cayenne_TTN_ABP.ino
Arduino IDEに利用するサンプルである。
上記は(株)オープンウェーブ様の手を加えられているようだが、参考のために冒頭のコメントの一部をコピーしておく。
このソースプログラムでTTNのデバイスで(自動)定義されたデバイスアドレス、ネットワークセッションキー、APPセッションキーを入力する。

  • Copyright (c) 2015 Thomas Telkamp and Matthijs Kooijman
  • Changed 2017.11.01 OpenWave inc,
  • Permission is hereby granted, free of charge, to anyone
  • obtaining a copy of this document and accompanying files,
  • to do whatever they want with them without any restriction,
  • including, but not limited to, copying, modification and redistribution.
  • NO WARRANTY OF ANY KIND IS PROVIDED.
    • Change DEVADDR to a unique address!
  • See http://thethingsnetwork.org/wiki/AddressSpace
    *
  • Do not forget to define the radio type correctly in config.h.
    *
  • Required Library:
  • * https://github.com/matthijskooijman/arduino-lmic
  • * https://github.com/adafruit/DHT-sensor-library
  • * https://github.com/adafruit/Adafruit_Sensor
    • Require Hardware:
  • * LoRa Shield + Arduino
  • * LoRa GPS Shield + Arduino
  • * LoRa Mini etc.
    • このサンプルは、The Things NetworkにABPで、DHT11の
  • 温度、湿度のデータをCayenneLPPのペイロードで送信します。
    • 2017.11.01 株式会社オープンウェーブ
      */

デバイス側で
使用周波数の設定、デバイスアドレス、ネットワークセッションキー、Appセッションキーを定義する。
不思議なのがPiに搭載したdual_cahn_pkt_fwd.cppである。ここでは使用する周波数やポートの定義はあるが、デバイスとのリンケージを示す定義をした覚えはない。もしかすると、ゲートウェイは同じ周波数帯で受信したものは、勝手にInternetに挙げてしまう懸念がある。 これはおいおい試してみたいところである。


確認方法
確認方法としてはまず、センサ側から順に確認してみたい。

Arduino IDEにあるモニターで確認する。(余分なDebug Messageとして読み込んデータを入れているが気にしないでください。)

次はゲートウェイである。
PiにLoginして、dual_chan_pkt_fwdのログを確認すればよい。

dual_chan_pkt_fwdはデーモンとして動作しているのでdaemon.logにメッセージが(延々と)記録される。 それの最後部分を何度か見ることによって動作がわかる。もちろんこのファイルをすべて見てもよいが大変である。
grep dual /var/log/daemon.log | tail
これを見ると5月5日 12:02:27にパケットを受信し、rssiやsnrなどの通信指標値が上がってきているのがわかる。
もし、これらのデータが全く見つけられなければ、dual_chan_pkt_fwdが動作しているかどうかを確かめるとよい。
ps -ef | grep dual

このコマンドを入力した後の1行目があれば、プログラムは動作している。
2行目はこのプロセスを探すためのプロセスが表示されているだけなので、無視する。
上記コマンドのtailをheadにすると、起動時のメッセージが見れるので参考にしてもらえるとよい。

ゲートウェイでの確認が取れたらTTNで確認する。
コンソール画面からアプリケーションを指定し、デバイスが登録してあるアプリケーションを開く。するとの設定の画面を見るとデータという項目があるので、そこをクリックする。

これが出れば一安心である。少なくともTTNまでの経路が確認できた。

ペイロード(Payload Formats)

ペイロードとはその名前の通り、電文を運ぶところである。MQTTに関していえば、このペイロードの使い方の規定はあまりない。最大256Byteというものはあるものの、デバイスのデータを利用するものが取り決めを行っている。
今回の事例ではCayenneを使用するのでCayenneに即した設定を行う。