mosaic X5 (mosaic HAT)で RTK 測位

少し使い方もわかってきたところで、RTK接続を。 でも、場所的には最悪なんだが、実現するかどうか。。。 ここ数年、自宅ではなかなかFixしなかったり、Fixしてもすぐに落ちたりしてており、結局屋外に出かけていたので正直設定と1度でもFixして動作確認ができればいいと思っていた。

しかし、結果はそれなりのFIXを得られて満足。 測位精度は屋外での実験を待ちたいが、現状では期待以上の結果が出ている。

さて、まず環境の紹介。

環境としては最悪かも。 次にシステム構成は下記。 PCを除くと写真の通り。

Wifi-Routerとmosaic HATとM5Stack Core2

今回の目的は、M5Stack Core2とmosaic X5をつかったRTKの実現である。

まずは、Core2が20km以上離れた場所のNtrip Serverに接続し、RTCM3の情報を得て、mosaicへ送信。mosaicからは、RTKのFix状態と位置情報を確認する。

まずは、RTKの設定をしない状態。

SBASが1衛星だけ補足していたが、単独測位との表示で±80cmといったところか。

衛星を半球しか捕まえていないところを見ると、かなり良い。 もしかしたらSBASが効いている可能性があるのだろうか。

従来の受信機ではこの状態だと軽く10mぐらいずれてしまっていた。次に、RTK測位を行っている場合、下記を見ると特にmosaic側での設定は不要のようである。

見ると、COM2にRTCM3が毎秒1kB程度づつ送られているのがわかる。

RTKもFloat解が出だした。

その後、Fixになり、それなりにほおっておいた状態が下の図である。

半球しか見えていないことと、これまでの実績を加味すると、このデータは結構よさそう。

その後、NMEAの出力を100mSに変えたが、Fix率が悪くなった。また、トレースで見切れていないのだが、(ここはu-centerが便利)RTKの送信が間に合わないのではないかという想像もしている。

どちらにせよ、個々のあたりはほかのアプリも組み込んだうえで調整が必要である。

また、少し気になるところとしては、Fixed RTKからStand-Aloneに落ち、Float解を経由してFix解となったときに、アンテナの位置は移動していないのだが、同じ場所を示さないという現象がある。

±15cm程度の誤差ではあるが、さらに良い環境で確かめる必要がある。

半球というところと、Ntrip Serverまでの距離が長いことと、Ntrip Serverの位置情報を入れていない事も十分考えられる。

今回は、M5がWifi-Router経由でNtrip Serverからのデータを受信し、mosaic X5に転送し、ちゃんとFix解が出るかどうかという実験だったので、それに関しては完了!

MOSAIC HAT (MOSAIC X5)の接続

さて、今度は、Septentrio社 の mosaic を試してみる。 X5という話なのだが、シルクにはmosaicとしかかない。

でも、ここに二次元バーコードが付いているので、読んでみると(URLかと期待した。) MOSAIC-X5GRB….

となっており、ちょっと安心。 mosaic-X5として扱っていける。
Webをみると、結構情報がある。 これまでubloxを使っているのはu-centerがわかりやすいという面がおおきかったが、どちらかというとマニア向けか。

ちょっと見たところでは、

データシートやマニュアル類、最新バージョンのファームの情報などは下記ある。

https://www.septentrio.com/en/products/gnss-receivers/receivers-module/mosaic#resources

そのほか、githubにもかなりの情報が公開されている。

https://github.com/septentrio-gnss/mosaicHAT

また、各種コンフィグレーションなどはRxToolsによって行われるが、下記からDownloadができる。

https://www.septentrio.com/en/products/software/rxtools#resources

ドライバも一緒にインストールされるので、あまり困ることはない。

さて、私のWindows環境にRxToolsをダウンロードし、ドライバと一緒にインストール。

そしてボードを見てみて、ANTとFTDI(USB/シリアル変換)で電源設定があるので、とりあえず両方とも3.3Vに指定して二周波のアンテナとUSBを接続。

一応動き出したが、場所の関係もあり、1GPS,1GLONASS.1BeiDou,1NavICしか入らない。 

ちょっと少し移動せざるを得ないか。。。

部屋の反対側に来て、作業性は悪いものの、半球は開放。さすがにあっという間に衛星を確保。

4GPS,7GLONASS,4Galileo,7BeiDou,1QZSSとなった。

方位が半円しか見えないためか、Main Signalの評価は半分以下しかあてにできない。 まぁ。しょうがないか。

まぁ、ほとんど設定も必要なくここまで来た。

そういえば、入江先生がWebで設定していたような雰囲気で話していたので、もしかしてと思い、pcの設定を確かめてみると、USB経由でLAN接続されているみたい。 また、192.168.3.1が怪しいので、さっそくChromeで接続してみると、これで十分設定できそうな画面が出てくる。

なんとなく感触はつかめた。 ふむ。 これは面白い。 

では次にGPSロボットカーのGPS部に使えるかどうか考えてみる。

まず、素材としてやらなけてばならないのは、

MOSAICの立ち上げ (この投稿部分が該当)

ロボットカー CPUへのNMEA送信(接続含む)

RTKの実現

というところか。

今回はMOSAICからシリアル通信でカーCPU ( M5 Stack Core2 ) へ通信。 

カーCPUというのもめんどくさいので、今使っているM5Stack Core2で実験。 ← ちょっとの遊びには結構高いんだよねぇ。。。 

まずは、Core2のアプリを作成。

要はMOSAICから受信したデータを画面に出すことと、USBでPCに送ること。

Core2上の画面では制御文字が出るとどうなるかわからないので、一か所にAscii CodeがHexで表示されるようにした。

また、Core2からPCにシリアルを送るのは、データを見たいだけではなく、トレースデータを見たいのだが、設定Webではそのような機能を探しきれなかったので、u-centerを使ってしまおうという考え。

Core2で作ったスケッチは下記。

#include <M5Core2.h>

#define RXD2 13 //HardwareSerial Serial2;
#define TXD2 14 //HardwareSerial Serial2;

static int i;

void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);  //USB to PC
  delay(100);
  Serial2.begin(115200, SERIAL_8N1, RXD2, TXD2);  // UART for GPS module
  delay(100);
  M5.begin(true, false, true, true); //LCD:Yes, SD:No, Seria:Yes, I2C:Yes
//  M5.Power.begin(); // Power ON for GPIO21,GPIO22 and I2C
  M5.Lcd.fillScreen(BLACK);
  M5.Lcd.setTextColor(GREEN , BLACK);
  M5.Lcd.setTextSize(2);
  M5.Lcd.println("M5 Started");
}

void loop() {  
  i = i + 1;
  if(Serial2.available() > 0) { 
    int data = Serial2.read();     
    Serial.write(data); 
    M5.Lcd.setCursor(0,20);
    M5.Lcd.println(data,HEX);
    M5.Lcd.println(i); 
  } 
}

何をやっているかというと、端子の定義とシリアルの定義(USBと端子)。

SerialのBufferに何かデータが来たら、そのままUSBに送信。 M5にはAscii Codeの16進数表示とLoop Counterの表示。

次にMOSAICとCore2の接続は下記。

Jumperスイッチとして3V3とVCCを接続。 ESP32のUARTは3.3V系のため。

シルクをみると、PWR SRCとあるので、VCCの電圧設定だけかもしれないが、念のため。

(こんな時にジャンクでとってあるJumper Switchが役に立つ)

CORE2側は

MOSAICもCore2もたぶんどちらもDCE側(端末側)。 なので、TXとRXD、RXとTXDを接続する。

ここは、ベンダーによってさまざまなので、だめなら逆に。 というレベル。

GNDはGND同士で接続。 MOSAICにはRTS/CTSの制御線があり、設計者のきちんとした意図が感じる。

でも、ごめんなさい。 使わないです。 Core2に無いし。 (仕事だと使うんですけどね)

つぎはMOSAIC-X5の設定。 Core2とMOSAIC-X5をともにUSBにつなげて電源ON。

192.168.3.1にアクセスして

Serial Portを指定して「Next」で次に

COM2を指定して、

好きなメッセージを選択してFinish!

最後にOK!!!! うーん。 簡単。 簡単。 

さらに、この更新周期に関しては期待大!

では、Core2の画面。

よさげ。

IDEのシリアルモニタの画面。

Good!

さらに、シリアルモニタを終了してu-centerでの画面。

Very Good!

u-centerでの設定 (NEO-M8P-2)

ちょっとu-centerの設定方法という相談があったので、ちょっと思い出してみました。

まずは、u-centerを最新版へ。 昨年はv20でしたが、いまみるとv22なんですねぇ。

v20を惜しみなくアンインストールし、u-bloxのWebからダウンロードしてインストール。

さっそくM8P-2にusbとアンテナを接続し、teratermで認識しているポートを確認。

今回は、COM3でした。

ためしにOKを押して少し様子を見ると、

接続はされている。 文字化けしているが、この辺りはアスキーコードの若い番号も来てしまうので、

御愛嬌といったところです。 ポートが正しいことと、読めていることを無事に確認。

こんなことをしているうちにダウンロードが終了し、u-centerのインストールへ。

インストールとともに、u-centerが起動されたので、tera termを終了してu-centerに

まずは、受信機のコネクションでCOM3を設定。

Packet Consoleボタンを押して

まずは、通信を確認。 位置は把握できていないようですが、衛星はある程度捕まえているので、

ちょっと先に進む。 ここは、テストするには環境が悪く、一部しかダメなんですよね。。。。

こんな感じです。

位置測位を開始していないところが気になるが、どんどん設定に進んでしまいましょう。・

[View]-[Configuration View]-[MSG]

ここで必要とするMSGを定義します。 ここにはいくつかの流派はあるので、自分の思い通りに。。

私は以下の設定。

出力はUSBとシリアルの両方としています。 (一応、、、) UART-2は今回はないので、設定しようとしてもSendした段階で消されてしまいます。

Robot Carで使用するNMEA MessageはGxRMCなんですが、U-Centerで感度やほかいろいろ見るときもあるので、最初はGxGGA,GxVTG、GxGLLも出力するようにしています。 (本番走行前で余裕があったときは、これらを外しています。)

 なので、こんな感じ。 都度、Sendを忘れないように。 一応2-3回チェックしたほうが良いです。

設定したつもりが変わっていないということはよくあること。 気にしない。

そのほかのNMEA Messageは以下の感じで出力しないようにしておく。

ゆっくりした制御なら出力しなくてもよいのですが、できるだけ余分な処理はトラブルの元なの潔く削除。

いつも限界で設定しておくと、トラブったときに、何が、何に関係していたかということがわかるので、それはそれでよしとします。

これが終わったらポートの設定。

左側よりPRTを選択して、UARTとUSBにUBX,NMEA,RTCM3を送受信できるように設定します。

速度は葉や右方が良いので、115200です。 USBで通信するのであれば関係ない。

下記はUART-1の設定だが、UART-2,USBも同じ設定に。 、と、UART-2が設定できなかったので、UART2は無視。

そして、保存します。 (一応保存されるような気もするが)

Packet Consoleを見てみるとGxRMCも出始めました。 よしよしです。

さて、次は、これをどのくらいの周期で出すかという設定です。

毎秒取れればOkという人は不要ですが、早くデータ収集したいという人は、Rateというメニューで設定します。 保存を忘れずに。 この通りにデータが来ると保証されているわけではないです。

せっかくなので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が見つけられない。。。。