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

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

使用したセンサーは(購入先は違うが)
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に即した設定を行う。

デバイスの定義

作成したアプリケーションを開くと、”デバイス(端末)”の定義がある。
デバイスの定義ではデバイスIDを入力するが、のちに出てくるCayenneとの連携がうまくいかないときに、デバイスIDをCayenne側で合わせたら動作した。変えたことが良かったのか、連携するときにデバイスIDが重要なのかは不明である。

デバイスEUIとApp Keyは自動生成されるが、この定義はセンサー側でアプリを作るときに連携される。

The Things Networkとは、とその定義

Project AはRaspberry PiにDevice(Node)と接続するためのLoRa無線機器であるLoRa/GPS HATを接続した。このProject Aの部分はGatewayなので、二つの通信の橋渡しを行う。このProjectではInternet上にあるTTN(The Things Network)との接続について述べる。

TTN(The Things Network)とは、たぶん世界最大規模の無料LoRa WANネットワークと紹介されているケースが多い。 ここを把握しておくことは重要であると思われる。

1.Internetへの接続
2.TTN へのアカウント定義
3.ゲートウェイの設定
4.アプリケーションの設定

1.Internetへの接続
LoRa ゲートウェイは各種のセンサの情報を集めてInternet上のTTNへ情報送る役目を持つ。そのために、LoRa ゲートウェイであるRaspberry PiはInternetへの接続を行う。今回は、自宅の無線LANに接続を行っている。このゲートウェイを移動させる場合は、モバイルルータなどに接続させることになる。 こらはRaspberry Piの通常の設定で問題ない。(Raspberry Piを立ち上げるためにInternetに接続しているはずなので、その設定で使われる方が多いであろう)

2.TTNへのアカウント定義
TTNへのアカウントは下記のURLより実施する。
https://account.thethingsnetwork.org/register
ここでUser NameやEMail Addressを入力するが、アクティベートが必要となるために、受信できるアドレスにする必要がある。また、一度使用したアドレスは再利用ができないので注意すること。

3.ゲートウェイの設定
サインインすると下記の画面となる。 この画面はコンソール画面と呼ばれ、作業する上でのホーム画面と考えればよい。

このTTNはMQTTにおけるBrokerの役割をなす。このBrokerとはセンサから適当なタイミングで送信されたMQTTのデータを受け取り、適切な受信者との橋渡しをする。
センサからは殆どのケースにおいてゲートウェイ経由で送られるので、まず右のゲートウェイの設定が必要である。
ここをクリックした後にゲートウェイを登録に進む。

また、EUIという言葉がこれから多く出てくるが、これは識別子の意味である。ゲートウェイEUIと言ったらゲートウェイを識別するためのIDでありデバイスEUIとであれば、デバイスを識別するIDである。もちろん世界で一つである必要がある。
ゲートウェイEUIといえば、ゲートウェイの識別IDである。TTNではMACアドレスの中間部分をFFFFにしたものが採用される。ほかのセンサ単位に割り振られるデバイスEUIなどは自動発番される。

記載した内容は適当であるが、Raspberry PiがInterenetに接続するインターフェースのMAC Addressを利用する。
今回は、Raspberry PiにDual_Chan_Pkt_Fwdを利用している。この場合、
I’m using the legacy packet forwarder”にチェックを入れる。
周波数計画は、日本で使用する場合、”Asia 923-925MHz”を選択しなくてはならない。
Routerはおすすめで、”ttn-router-asia-se”が出てくるので、これを用いる。
当然Raspberry Piがわでもこの設定をしている必要がある。

場所についてはMapが現れるので、ダブルクリックすれば緯度経度が自動入力されるので非常に便利である。

4.アプリケーションの設定
アプリケーション設定ではゲートウェイから上がってくるデータの振り分けやほかのアプリケーションとの連携の定義を行う。ほとんどのケースにおいて多くのデバイスを分類して、その分類ごとにアプリケーションを作ることとなる。
アプリケーションの登録には、自由に設定するアプリケーションID、その説明文、(自動的に割り振られる)アプリケーションEUI、ハンドラー登録を行う。これは、想定だが、ここで定義するハンドラー登録には”ttn-router-asia-se”を定義する。
また、過去に一度登録したアプリケーションIDは使えないようである。

ここで定義したアプリケーションにデバイスと連携するサービスを割り付けていく。
一覧から作成したアプリケーションを開けてみると、
アプリケーションオーバーフロー
アプリケーションEUI
デバイス
コラボレータ
アクセスキー
が表示される。

アプリケーションオーバーフロー
ちょっとどっきりするエラーやワーニングを示している項目に思えてしまうが、
どうやら”アプリケーションオーバービュー”と言いたかったのか? 不明である。

アプリケーションEUI
これはこのアプリケーションを示すIDでありこのTTN内では固有のものとなる。(自動発番)

デバイス
ここにデバイスを登録することによってデバイスからのデータを受けれるようになる。

コラボレータ、アクセスキー
ここは、意識的に定義はしていない。定義したユーザやデバイスとメッセージをつなぎつけるキーが自動生成されるようである。

代品の入手

故障を断定した後は、代品をどうするかという話である。

いっそのこと既製品のLoRa Gatewayを購入してそのサービスを体験しようという考えもあり、SORACOMのGatewayにはかなり興味を持っていた。
しかし、本当にHATの故障を証明したいのと、まずは素材レベルでいろいろと知見を確保したいので結局HATを購入することとした。

新しいHATが到着後、、おそるおそるPiに接続して動作確認すると、下記のように問題なく立ち上がった。

pi@raspberrypi:~/dual_chan_pkt_fwd $ ./dual_chan_pkt_fwd
server: .address = router.jp.thethings.network; .port = 1700; .enable = 1
server: .address = router.as2.thethings.network; .port = 1700; .enable = 0
Gateway Configuration
XXXXXXXXXXXXXXXXXXX ← ここは自主規制
testing IoT
Latitude=0.00000000
Longitude=0.00000000
Altitude=10
Interface: wlan0
Trying to detect module CE0 with NSS=6 DIO0=7 Reset=3 Led1=unused
SX1276 detected on CE0, starting.
Trying to detect module CE1 with NSS=6 DIO0=7 Reset=3 Led1=unused
SX1276 detected on CE1, starting.
Gateway ID: xx:xx:xx:ff:ff:xx:xx:xx ← ここは自主規制
Listening at SF10 on 923.200000 Mhz.
Listening at SF10 on 923.200000 Mhz.
stat update: 2020-05-03 00:36:27 GMT no packet received yet
stat update: 2020-05-03 00:36:57 GMT no packet received yet

そのた、ここ似たどつくまでに試したものとしては、

Single_chan_pkt_fwdもWebで見つけて試してみた。動作を確認するためにはプログラムがシンプルで大いに助かった。

SPIの調査

(ちょっと効果的だったあがき1)
怪しいのはSPI。でもSPIの機器はちょっと考えてみたのだが、手元にはなさそう。
そこで、考えたのが、とりあえず自分で折り返してPi側の健全性を確認する。
まずは、SPI関連のモジュールを確認した。

参考にさせてもらったのは下記のページ。
https://tomosoft.jp/design/?p=5428

これで、動作確認をしてみると、Piのみで配線を折り返してLoopbackを実施すると問題ない。試しにLoopBackの配線を外した結果と。HATを接続した場合は同じ結果となる。
ここまで、証拠を突きつければおのずと、HATの単品故障と断定した。

SPI機器の動作がうまくいかないときにはおすすめである。