LoRaWANによるセンサーの強化

既存のセンサ端末に低電力・長距離ワイヤレス通信機能を追加

端末どうし”つながる”ことがこれまでになく容易になってきつつある。今回紹介するLoRaWANとネットワークインフラ The Things Networkにより、ルータやゲートウェイ(LoRaWAN基地局)から遠く離れた場所のセンサーのデータを収集し、インターネットを介して確認できるといったことが信じられないほど簡単にできるようになってきた。

今回の例では、LoRaWAN、GPSなどに対応したSmartEverything LION (124-8830) Arduino互換ボードとコウモリ検出用のArduBatシールドを組み合わせて、超音波を使ったコウモリの検出を行う。これは他のシールドや接続センサにも簡単に応用できるはずだ。

LoRaWAN

LoRaWANの実に素晴らしい点の1つは、誰でもネットワークを構築できる点だ。ゲートウェイは比較的安く、設定もシンプルである。LoRaWANバックエンドにはさまざまなオプションがあり、アプリケーションとの間のデータのルーティングやデバイスの起動などを担う「ネットワークコア」と見なすことができる。これらのオプションには、The Things Network (グローバル)、Things Connected (UKのみ)、スタンドアロン（単独稼働）/セルフホストソフトウェア（自コンピューター内でホストを稼働）といったソリューションなどがある。

私たちのいる場所は、何台かのThe Things Network (TTN)接続ゲートウェイでカバーされている。つまり、インフラを準備する必要はなく、ノードを用意するだけで、この公共利用可能なネットワークを使用できるのだ。近くにゲートウェイがない場合も、TTNを利用して新しいゲートウェイを簡単にセットアップし、さらに、ゲートウェイをコミュニティで共有することで通信範囲を拡大できるメリットもある。

もしかしたら、あなたはすでにゲートウェイにアクセスできるかもしれない。近くにゲートウェイがあるかどうかを調べるには、マップを確認してほしい。ゲートウェイまで障害物が何もない場合や建物がいくつもない場合、障害物が少なくなるためゲートウェイに接続できる可能性が高くなるだろう。

これらのネットワークで使用されているワイヤレステクノロジー(LoRa)は驚くべき最新技術だ。多くのワイヤレスキーフォブ（自動車などのリモコンキー）やドアベルと同じ868MHzの無線スペクトラムを使用している(EU及び他の地域では異なる周波数を使用)。キーフォブの通信距離はせいぜい30mくらいだが、LoRaの通信距離は容易に3,000m、最大で15,000mにも達する。この数字は誤りではなく、本当に15kmが実現可能なのだ。

この極端に広い通信範囲は、昔から知られていた「巧妙な物理現象」を市販の電子機器に実装することによって実現されている。この「巧妙な物理現象」とは、多くの無線通信のように単一の周波数を使用するのではなく、FM変調チャープ信号を固定信号に変調することで、LoRaの波形を「拡散」させることだ。この技術は、チャープ拡散スペクトラムと呼ばれている。信号をアップチャープ（周波数を増加）することで、背景ノイズやさらには帯域内/外緩衝から信号を取り出すことがはるかに容易になるのだ。

データをエンコードする方法も、通信範囲をできるだけ広げることを考慮しており、これら2つの技術により、驚くべき長距離通信が実現可能となっている。

LoRaWANにおけるWAN

LoRaWANのワイドエリアネットワーク(WAN)部分は、IoTでスマートに処理する。ノード部分は、LoRaプロトコルと合わせて、SmartEverything LIONのMicrochip RN2483モジュールによって処理される。ゲートウェイがTTNとやり取りされるデータのパケットを転送するので、ユーザーが行うことはノードをこのネットワークに接続することくらいだ。ネットワークの重複回避や、ゲートウェイ管理、データ転送、暗号化とセキュリティなど、残りはすべてゲートウェイがやってくれる。

コウモリの検出

ほとんどのコウモリ検出器は、コウモリがエコロケーションに使用する超音波チャープ信号を検出することで実現している。チャープの長さと周波数から検出したコウモリの種を特定することができる。コウモリ検出器はすでに市販されているが、LoRaWAN対応のものは見つからなかったため、私たちのものが世界初になるかもしれない。

Ardubat検出器は、市販のものと比べて一部に制限がある。たとえば、高kHz範囲では若干感度が悪く、キクガシラコウモリ/ヒメキクガシラコウモリ(80～100kHz)を検出できない可能性だ。また、録音はしないため(記録するのはパルス周波数と持続時間のみ)、一部の種の区別が困難となってしまっている。

コウモリ検出器の特性から、以下について考慮する必要がある。

• バッテリで長時間動作すること
• WiFi及び電力から距離のある野外又は小屋に静的に設置すること

私たちのデバイスについて

Arrow SmartEverything LION開発プラットフォームは、まとまったパッケージとして販売されているArduino互換のLoRaWANデバイス/IoT開発キットだ。

このデバイスで最初にすべきことは(どんなLoRaWANデバイスでも同様なのだが)、HWEUIを調べることだ。これはネットワークアクセスに使用するノードの一意の識別子だ。多くの人が知っているであるMACアドレスのようなものだ。

この識別子の取得方法はデバイスごとに異なり、LIONの場合にはいくつかの方法がある。最も簡単なのはサンプルコードの「getChipInformation」をロードする方法だ。この方法ではシリアルポートに識別子が出力される。もう一つの方法は、以下のコードをメインアプリケーションに入れる方法だ。この方法では、RN2483モジュールに直接アクセスできるようになり、コマンド「sys get hweui」で問い合わせることができる。

  if (Serial.available()) 
  {
    c = Serial.read();  
    Serial.write(c); 
    buff[i++] = c;
    if (c == '\n') 
    {
      Serial.print(lora.sendRawCmdAndAnswer(buff));
      i = 0;
      memset(buff, 0, sizeof(buff));
    }
  }

The Things Networkのセットアップ

The Things Networkのアカウントのセットアップは簡単だ。通常のアカウントセットアップ手順に従うだけで、登録が完了し、数分でネットワークにアクセスできるようになる。次にTTNコンソールに入り、ノードをセットアップしていく。

[Applications (アプリケーション)]タブに移動し、最初のアプリケーションを追加する。

この後、デバイスを登録する必要があります。デバイスの概要は次のように設定する。

この部分の入力が完了すると、LoRaWANデバイスが設定され、Arduinoのコードを実装するとデバイスがThe Things Networkに接続できるようになる。

SmartEverything LIONについては以前に解説したので、この手順はスキップするが、手始めに「sendDataOTA_console」サンプルを使用して、セットアップとネットワーク接続をテストしてみるのもいいかもしれない。このサンプルで改変が必要なのは、以下の部分だけでよい。情報は、TTNアプリケーションの[DEVICE OVERVIEW (デバイスの概要)]タブで見つけることができる。

err = lora.macSetAppEUICmd("0000000000000001");

lora.macSetAppKeyCmd("ffffffffffffffffffffffffffff0000");

ネットワークの制限

LoRaWANを使用する場合に知っておくべき重要なポイントは、データ帯域幅が非常に狭い点だ。

使用可能な限界はチャンネルあたり約1%だ(ただしこの値は変動する)。これはモジュール(この例ではRN2483)に課せられる厳しい制約になるだろう。また、この制限はゲートウェイにも課せられる(詳細は後述)。

さらに、TTNにはフェアアクセスポリシー（公平なアクセス権）があり、ノードのアップリンクが24時間あたりエアタイム（通信時間）30秒、ダウンリンクが1日あたり10メッセージに制限されている。ゲートウェイもこのTX制限に従う必要があるため、ゲートウェイからの応答は保証されていない。特にゲートウェイ上で誰かがフェアユースポリシー（公平な使用権）に違反した場合は応答がないことがある。

LoRaWANでは、OTAA (over-the-air activation)とABP (activation-by-personalisation)の2種類のプロビジョニング方法が用意されています。ABPは非常に割り切った手法で、一度設定したキーを変更することなく使い続けるといったものだ。これは、暗号化キーが一切変更されないため、セキュリティ上の問題となる恐れがあり、長期間使い続けると簡単に突破される可能性をもたらしてしまう。

OTAAでは、接続のたびに新しい暗号化キーが割り当てられるため、デバイスを再起動して再接続を強制することでキーを更新できる。この2番目の方法は、少々使い勝手が悪く、ゲートウェイからの応答に依存している。つまり、ゲートウェイがビジー状態だったり、TXの割り当てを使っていたりすると、接続に成功するのに時間がかかってしまうということなのだ。

今回の例の適用

ここまでで述べてきたように、今回の例を他の用途に適用したときに、いくつかの制限が判明した。

• メインループでタイミングをうまく制御することができず、ワイヤレスモジュールに何度もメッセージを送信する場合があること
• 上記のタイミングの調整の問題が原因で、コードの追加が問題になる可能性があること
• そのためRN2483がTX要求を拒否し、接続問題が発生する可能性があること

この問題を解決するには、より正確なタイミングループを実装し、TXイベント（送信イベント）を何十分かに1回に制限する必要がある。最終的なアプリケーションでは60分を設定値にすることになるだろう（つまり60分に一回）。SF7BW125の最小拡散係数(最小範囲)では、2バイトのペイロードが通信1回あたり約45ミリ秒のエアタイムを消費し、1日あたりの総TXエアタイムは約1秒になります。SF12 (最大範囲)になると、この時間は27.6秒になる。これはフェアユースポリシーに違反せずにノードで使える全エアタイムとほぼ同じ、つまり限度いっぱいだ。

LoRaWANでは、この拡散係数の差異を考慮し、すべてがSF7で行われると仮定しないことが非常に重要なのだ。さらに広範囲であることを示すSF12になる可能性も十分にあり得る。この点に注意して、この例から多くのコードを「LoRa_TX」という関数に移植していく。送信されたデータは独自の文字列に置き換え、確認済みのTXに条件チェックを追加して、定期的に使用することを決定できるようにする。

if (MAC_JOINED(state)) 
{
   if (!joined) 
   {
     Serial.println("\nOTA Network JOINED! ");

     joined = true;
   }
     
   tx_cnt++;

   if(Confirmtx==true)
   {
     Serial.println("Sending Confirmed String and clearing count...");
        
     returned = lora.macTxCmd(String(s), 1, TX_ACK); // Confirmed tx check received ok so we can clear the count
     if(Serialdebuglevel <=1)
     {
        Serial.println(returned);
     }
     if(returned == "RN_OK")
     {
            
        BatsDetected =0; // clear bat count
     }
        Confirmtx=false;
   }
   else
   {
        Serial.println("Sending UnConfirmed String ...");
        lora.macTxCmd(String(s), 1);  // Unconfirmed tx buffer if required
   }
          
} 
else 
{  
   joined=false;// Network is not joined so try to join
   Serial.println("\nNot Joined Tying to Join");
   lora.macJoinCmd(OTAA); // wait a while after joining
   delay(4000);
} 

メインループのコードはあまりない。

void loop() 
{
  static bool joined = false;
  
  LoRa_management(); // in here we relay commands to the RN2483 and deal with RX.
  bat_detection_loop(); // bat related items get done here
  checktime(); // this keeps track of time (must be entered a few times per second to avoid loss of time)
  Time_to_tx(); // check the set the flag Go_Tx when we are ready to tx.
  
  if (Go_Tx) 
  { 
    Serial.println("\nTry to TX:\n");
    LoRa_TX(String(BatsDetected)); // this sends the Bat string
    Go_Tx=false;
  }
}

必要なグローバル変数を気前よくどんどん追加してセットアップしていこう。これはほめられたことではありませんが、ここでは経験のため、ということで正当化させてほしい。それではアプリケーションをオンにして、The Things Networkに接続しよう。

改善

現時点では、コードはコウモリの累積カウントを保持し、未確認の60分ごとにこの値を送信するのみだ。そしてアップリンクが確認された後、12時間ごとにカウントはリセットされる(カウントがリセットされるのは送信が成功した場合のみ)。

考えられる改善点

• 理想的には、ネットワークアプリケーションで制御し、ダウンリンクの送信によるカウントリセット機能を実装すべき。
• コウモリの検出性能はそれほど高くなく、周波数と受信パルスの持続時間に基づいて適切に「破棄」する必要がある。これは単にコーディングと実験の問題だ。
• ログはSDカードに出力すべきです。
• システムはかなりの電力を消費しており、ハードウェアタイミングとスリープルーチンを工夫することで、バッテリ運用をさらに実用的にできるはずだ。
• 最後に最も重要な点だが、ASCIIエンコード文字列を使用しているため、データが少々大きくなっている。理想的には、データを圧縮して冗長データを除去し、バイナリのみを送信するハンドラが必要だ。

最後に

任意のセンサにLoRaWAN機能を追加することは、比較的些細なことだ。何事もそうであるように、改善の余地があるものの、コアな機能は簡単に達成できる。

このテクノロジーは極めて低電力な無線通信を可能にし、長期的に記録を行う用途に最適だ。いくつかの制約がありますが、その制約を知り、それに従って実装することで、ほとんどどんなセンサにも使用できる信頼性の高い、低コストなシステムを作成できるだろう。

Karl Woodward