WINLIVE リアルタイム⾵映像 – LoRaWAN で計測値を⻑距離伝送する

はじめに

株式会社 WinTicket バックエンドエンジニアの鈴木です。

本記事では、競輪場での風可視化システムにおいて、観客による電波干渉と回線逼迫で通信が不安定になる問題を、LoRaWAN 技術の導入によって解決した事例を紹介します。

風可視化システムの導入に取り組んだ記事は WINLIVE における風可視化の取り組みをご参照ください。

想定読者

IoTデバイスを使ったシステム開発に携わるエンジニア
無線通信技術（特にLPWA）の選定・導入を検討しているエンジニア
LoRaWAN の実装経験を積みたいエンジニア
電波干渉や通信不安定の問題に直面しているエンジニア

この記事で学べること

競輪場のような大規模イベント会場での通信課題とその解決方法
LoRaWAN 技術の選定理由と実装手順
LoRaWAN 実装時の注意点とトラブルシューティング
データ形式の最適化による AirTime 削減の重要性
AWS IoT Core for LoRaWAN を使ったシステム構築方法

背景と課題

従来システムでは風速計指標の送信に Wi-Fi 2.4GHz 帯と、キャリア回線（4G）を利用して実現しています。
当初は一部区間の電波強度が弱いという懸念があったものの、風可視化の実現には問題ないとの判断で進行していました。しかし、回数を重ねていくうちに何らかの影響で電波状況が悪くなり、指標送信が度々不通となる事象が発生していました。

Wi-Fi 2.4GHz 帯は電波が遠くまで届き壁や床などの障害物を回り込みやすい性質がある一方で、水に吸い寄せられやすく電波干渉しやすい特性があります。
また、最近では競輪場でスマホ通信や Bluetooth 機器を利用するユーザーが増えたことで、グランプリなどの大規模イベント時に「ネットに繋がらない」というご意見を度々耳にしており、4G回線を利用した通信も現実的ではありません。

2025年12月28〜30日に平塚競輪場で開催された 「ＫＥＩＲＩＮグランプリ２０２５」 では、場内が観客で超満員になるため、現状のままでは安定した通信を実現することは困難です。

技術選定時点で本番開催まで残り２ヶ月を切っており、開発・検証のコストを最小限にすることを最優先として、Wi-Fi 2.4GHz の弱点とキャリア回線（4G）によるインターネット不通を解消する必要がありました。

解決方針の選定

ここで着目したのは LPWA（Low Power Wide Area）規格です。
少ない消費電力で広範囲の通信を可能にする無線通信技術として幅広い産業で活用されています。

規格	評価	メリット	デメリット
LoRaWAN	○	長距離通信、省電力、電波干渉回避、プライベート網構築可能	送信間隔制限（10-30秒）、Gateway 設置・運用管理が必要
Private LoRa	◎	リアルタイム送信可能、Gateway 不要、月額費用無料	1対Nの広域多点接続には不向き、ネットワーク管理機能を自作する必要あり
Sigfox	✕	世界共通ネットワーク、基地局の設置不要、デバイス価格・通信料が安価	1日の送信回数制限（最大140回）、データ量が極少、下り制御が弱い
Wi-SUN	✕	メッシュ通信で広範囲カバー、日本のスマートメーター標準で信頼性が高い	通信距離がLoRa等に比べて短い、マルチホップ時の遅延が発生しやすい
Wi-Fi HaLow （802.11ah）	○	LPWA中で高速（映像伝送可）、IP通信可能で既存ネットワークと親和性が高い	消費電力がやや大きい、対応デバイスが発展途上でコストが高め
Wi-Fi 2.4GHz	△	高速通信と低遅延、スマホやPCと直接接続可能、汎用性が高い	消費電力が大きく電池駆動に不向き、障害物に弱く通信距離が短い、電波干渉しやすい

まず最初に注目したのは Wi-Fi HaLow です。近年注目されつつある規格ですが導入事例はまだ数が少なく市場に出回っている機器が多くありません。
次に Private LoRa に着目しました。リアルタイムに送信できる点は最大のメリットでしたが、データの送受信手順（ハンドシェイク）やエラー処理をすべて自前で設計・実装する必要があり、開発におけるイニシャルコストが高く現実的ではありません。

最終的に実装コストと機器調達の手軽さから LoRaWAN を採用しました。

従来システムでは、センサーと Wi-Fi ルーターの通信距離をギリギリまで詰める必要があり、ルーターの配置場所が限られていました。LoRaWAN の長距離通信の特性によりこの制約が解消され、屋内窓際に Gateway を設置できるようになりました。これにより有線 LAN に切り替えることができ、4G 回線も併せて廃止できました。

利用する際の事前確認ポイント

LoRaWAN をビジネス用途で「指標送信技術」として活用する際は、導入前にいくつかの重要な観点を整理しておく必要があります。以下では、制度・設置・技術の各観点から、事前に確認すべき要素をまとめます。

法制度・規制面の確認

LoRaWAN は日本では主に 920MHz 帯の特定小電力無線として利用されます。この帯域は免許不要である一方、使用機器が技術基準適合（技適）を満たしていること、ならびに送信出力や送信時間などの技術条件を遵守することが前提となります（詳細は「機器選定」セクションを参照）。

ゲートウェイを一般開放せず、閉じた用途で利用する場合であっても、電波法上の扱いが変わるわけではない点に留意が必要です。

利用形態とデータ内容の整理

本システムでは状態や変化を示す「指標」を送信する用途として位置づけており、送信するデータは最小限に設計し、通信回数や占有時間を抑える前提が、制度面・運用面の双方で安定した利用につながります。

設置場所に関する事前確認

ゲートウェイや端末を設置する際は、建物管理者や施設運営者の許可取得が必要となります。特に屋外設置やアンテナ設置を伴う場合は、事前の合意形成が不可欠です。
あわせて、周辺の電波利用状況や設置環境を簡易的に確認し、想定した通信が成立するかを事前に検証しておくことが望ましいです。

通信方式・セキュリティの前提整理

LoRaWAN 固有の認証・鍵管理方式を理解し、デバイスを適切に管理することが求められます。指標データであっても、不正送信やなりすましは事業リスクとなるため、最低限のセキュリティ設計は事前に整理しておく必要があります。

LoRaWANとは

LoRaWAN は物理層に LoRa 方式を採用し、ネットワーク層プロトコルを内包している通信規格です。

ワイヤレスデバイスの仕様は、LoRaWAN バージョンと認証プロセスで構成されます。

LoRa の物理層のみを使った通信（LoRa P2P など）では、メッセージ送信がブロードキャスト方式のため、同じ周波数帯で受信できる機器があれば容易に盗聴できてしまいます。一方、LoRaWAN では OTAA（Over-The-Air Activation）方式を採用することで、デバイスとサーバ間の認証とデータ送信時の暗号化・復号化を自動で行い、セキュリティに配慮された環境で通信できます。

今回は利用する機材に組み込まれている LoRa モジュール ES920LR3 の仕様にあわせ OTAA 方式を採用しています。決められた項目（DevEUI、AppKey、AppEUI）を設定しておくだけで、デバイス・サーバ間認証とデータ送信時の暗号化・復号化の処理を全て自動で解決でき、運用性にも優れています。

システム設計

全体アーキテクチャ

AWS Cloud サービスでは LoRaWAN を簡単に管理運用できる AWS IoT Core for LoRaWAN が提供されています。

従来方式で利用していた AWS IoT Core では、MQTT Topic に送信するだけで IoT Topic で扱うことができます。
一方で LoRaWAN Protocol 非対応のため、AWS IoT Core for LoRaWAN へ切り替える必要があります。
このサービスはデバイス認証から指標の受信までを担うため、後段で指標の送信先を IoT Rule に設定し、既存の IoT Topic へルーティングして従来と同じフローで処理できるようにしています。

閉域網を利用した通信

クラウドとの通信には、映像伝送用の経路として既に敷設されていた AWS Direct Connect を利用しました。

引用: AWS IoT Core for LoRaWAN privatelink アーキテクチャ

AWS IoT Core for LoRaWAN への接続は、パブリックインターネット経由ではなく、Virtual Private Cloud（VPC）内のインターフェイス VPC エンドポイント（AWS PrivateLink）経由で実施できます。
VPC インターフェイスエンドポイントを使用することで、AWS ネットワーク内で VPC と AWS IoT Core for LoRaWAN 間の通信を完全かつ安全に実施できます。
LoRaWAN のエンドポイント（LNS、CUPS）に対する PrivateLink を作成することで、AWS Direct Connect 経由で接続を実現しました。

データ形式の最適化

従来のシステムでは、以下のような JSON 形式でセンサデータを送信していました。

{
  "nodeId": 1,
  "windDirection": 252,
  "airSpeed": 0.05,
  "virtualTemp": 22.25
}

JSON は可読性が高く、デバッグや拡張が容易であるため、システム初期段階では非常に扱いやすい形式です。
しかし LoRaWAN のような 低速・長距離・省電力を前提とした無線通信では、文字情報が多く冗長になりやすく、データサイズ増加により AirTime が無駄に増えてしまいます。

LoRaWAN では 1 回の送信が電波を占有する時間（AirTime）が長いため、送信データ量を適切に設計し AirTime を最小化しないと、送信頻度が低くても電波法の制約に抵触するリスク があります。

電波法として守るべき指標値の考え方

日本の 920MHz 帯では、「どれだけ長時間、どれだけ頻繁に電波を発射してよいか」が技術条件として定められています。
LoRaWAN の設計では、一般的な設計目安として、1 時間あたりの送信時間を 1%（36 秒）以下 に抑えるという Low Duty Cycle 的な考え方がよく用いられます。
ここで重要なのは、評価対象は「送信回数」ではなく、「AirTime の合計」である点です。

送信データ形式の比較

ここでは同じセンサーデータを異なる形式で表現して比較します。

① JSON minify（68 バイト）

最も分かりやすい形式ですが、冗長な書式のためデータサイズが大きくなりがちです。

{ "nodeId": 1, "windDirection": 252, "airSpeed": 0.05, "virtualTemp": 22.25 }

② JSON 短キー（34 バイト）

キー名を短縮することで、JSON の可読性をある程度保ちつつサイズを削減します。
しかし、依然として文字数は多く小数点や文字コードのオーバーヘッドが残ります。

{ "n": 1, "w": 252, "a": 0.05, "t": 22.25 }

③ CSV 形式（16 バイト）

キーを省略し、順序で意味を解釈することで、JSON よりもかなり軽量になります。
実装も容易で、「テキスト形式である程度小さくしたい」場合には有効です。
一方で、数値が文字列である点は変わらず、将来的な拡張には注意が必要という懸念があります。

1,252,0.05,22.25

④ 固定長バイナリ形式（7 バイト）

項目単位の数値範囲に合わせた固定長バイトで区切り文字情報を完全に排除します。

このときの 固定長バイナリ（7B） は、以下の固定長で表現します（little endian 固定、符号付き整数は 2 の補数）。

項目	意味 / 単位	形式（格納）	ビット数	バイト数	数値範囲（実数）
`nodeId`	ノード識別子	`uint8`	8	1	0 〜 255
`windDirection`	風向 / degree	`uint16`	16	2	0 〜 65535（運用上は 0〜359）
`airSpeed`	風速 / m/s	`uint16`	16	2	0.00 〜 655.35 ×100 （0.01 m/s 単位）
`virtualTemp`	仮想温度 / ℃	`int16`	16	2	-327.68 〜 327.67 ×100（0.01 ℃ 単位）

サンプル値を上の定義で格納したときの 7 バイト（16 進）は次のとおりです。
データ内容を目視確認し難いデメリットはありますが、最小のデータサイズを実現できます。

01 00 FC 00 05 08 B1

データ送信形式のまとめ

これまでに算出したデータ形式のペイロード長を元に AirTime を算出してみます。

形式	ペイロード長（B）	AirTime @SF7（ms）	AirTime @SF12（ms）
JSON（minify）	68	123.136	2957.312
JSON（短キー）	34	77.056	1810.432
CSV	16	51.456	1318.912
固定バイナリ（7B）	7	36.096	991.232

ペイロード長に比例して AirTime が増えるのは明白ですが、LoRaWAN のように AirTime が支配的な通信方式では、固定バイナリ形式が最も理想的な選択肢となります。
どれも 1 回の送信時間は少ないですが、これが後々に 送信頻度を最大化できる余地 として大きく影響してきます。

AirTime の算出と送信頻度の決定

固定長バイナリ 7 バイトに LoRaWAN ヘッダー（およそ+13B）を加えた約 20 バイトのペイロードで、SF7 設定時の AirTime は約 56 ms となります。

従来の毎秒送信を前提とすると、1 時間あたりの送信時間合計は約 202 秒となり、設計目安である 1%（36 秒／時） を大きく超過します。さらに実運用では ACK や再送による送信回数の増加、SF 変動による AirTime 増加、他デバイスとの電波衝突などが発生するため、毎秒送信は成立しません。
1%（36 秒／時） を目安にするなら、送信間隔は少なくとも 6 秒以上が必要です。再送や SF 変動の余裕を見込むと、送信間隔 10 秒（1 時間あたり約 20 秒）が現実的な落とし所となります。

仮に JSON 形式のまま送信すると AirTime は 10 倍近い数値となり、送信頻度が 60 秒以上になってしまうのは容易に想像できます。LoRaWAN を用いたシステム設計では、送信データ形式の選択そのものが電波法適合性とシステム健全性を左右する という点を強く意識する必要があります。

機器選定

LoRaWAN で使う LoRa 無線は 920MHz 帯域を利用するため、日本国内で利用する機器には技適認証が必須です。また、技適認証があったとしても、電波出力が基準（20mW 以下）を超えるものは特定小電力無線機に該当しないため、総務省への届け出が必要になることにも注意が必要です。

LoRaWAN Gateway（親機）

引用元: ビルトインサーバー LoRaWANゲートウェイ LPS8 v2-JP

今回は風速計デバイス 9 つの小規模な通信のため、事業者向けのハイパフォーマンスな機器は不要です。そのため比較的安価で、かつクラウドと親和性の高い Dragino LPS8 v2-JP を採用しました。

ブラウザからこの製品のコンソール画面にアクセスし AWS IoT Core for LoRaWAN で発行した証明書とエンドポイントを設定するだけで簡単にクラウド環境と接続できます。また、特定無線設備の種別として「第２条第８号に規定する特定無線設備」が適用されているため、機器種別が 特定小電力無線機 に該当し、安心して利用できます。

これらの機器が取得している技適認証の詳細情報の確認は総務省電波利用ポータルより検索できます。

LoRa 無線モジュール（子機）

風速計 ULSA M5B は M5Stack デバイスを経由して受け取るため、何らかの外部モジュールを組み込んで実現することが最短経路であると考えました。
M5Stack で利用できる LoRa 無線機器は多々ありますが、その殆どが LoRa チップ側で技適認証が取得済みのため安心して選定できます。

製品名	接続方式	LoRa モジュール	LoRaWAN対応	技適認証
M5Stack用LoRa無線ユニット（ES920LR3）	GROVE端子	ES920LR3	✅ 対応（ファームウェア更新要）	✅
M5Stack用LoRa無線モジュール (ES920LR3)	M-BUS	ES920LR3	✅ 対応（ファームウェア更新要）	✅
M5Stack用LoRaユニット JPバージョンアンテナ付（E220-900T22S）	GROVE端子	E220-900T22S	❌ 非対応（LoRa物理層のみ）	✅

ULSA M5B と M5Stack の接続には M-BUS を既に利用しているため、LoRa 無線モジュールは別の接続経路が必要でした。今回は未使用の GROVE 端子接続が可能で LoRaWAN に対応している製品を選定しました。
なお、一部の製品は LoRaWAN 非対応（LoRa P2P 向け）のものがあり、誤って購入すると通信を確立できないのでご注意ください。

実装手順

AWS Cloud の設定

まずは Gateway 機器に関する設定です。
機器の裏面、もしくはコンソール画面に記載されている16桁の Gateway EUI を転記します。このキーは AWS クラウド上で一意になる必要があるため、他アカウントも含め重複して登録できません。
日本国内における周波数帯は必ず AS923-1 を指定します。これは日本を含むアジアの国々に使われる規格で、920MHz帯（920～928MHz）の周波数を使用します。

登録が終わると Gateway 機器に関連する証明書やエンドポイントが発行されます。これは１度しか表示されないため確実にダウンロードとコピーをしておきましょう。

次に指標を送信する側のデバイスの登録です。
先述の OTAA 方式に従い、ワイヤレスデバイスのチップ仕様に合わせて OTAA v1.0.x とし、キー項目を３つ設定します。コンソールの項目説明からは「全てチップ製造メーカーに発行してもらう」と解釈できますが、これは間違いです。

DevEUI（16桁16進数）: チップ製造メーカーに端末単位で発行してもらう
AppKey（32桁16進数）: クラウド管理者が発行する（生成例: openssl rand -hex 16）
AppEUI（16桁16進数）: クラウド管理者が発行する（生成例: openssl rand -hex 8）

AppKey はルート暗号鍵となるため取り扱いには注意が必要です。DevEUI、AppEUI は機密情報には当たりませんが、役割として MAC アドレスに近いもので攻撃対象として扱われる可能性があるため、これらの項目はまとめて Secrets Manager などで管理することをおすすめします。

Gateway 機器の設定

Dragino LPS8 をインターネット接続できる状態にしたうえで、ブラウザで Gateway コンソールを開きます。
コンソール > LoRaWAN を開き、Service Provider は Amazon - IoT を選択します。
先程の AWS クラウド上で発行した証明書やエンドポイントをそれぞれの対応する項目に設定していきます。最後に Save&Apply ボタンを押下し Current Mode が Basic Station -- AWS になっていれば設定は完了です。

先程の AWS コンソールの Gateway に戻り接続ステータスを確認します。これまでの設定が正しく完了していれば殆ど待ち時間なく Connected 状態が確認できます。
余談ですが、画面少し下の「概要メトリクスをアクティブ化」を設定しておくことで、アクティブ時のメトリクスを自動的に収集しグラフ可視化できるので問題発生時に活用できます。

IoT デバイスの設定

チップファームウェアの書き換え

LoRa無線ユニットで使われている LoRa モジュール ES920LR3 はデフォルトでは LoRa無線を使った相互通信のみをサポートしており、LoRaWAN の利用には ファームウェアの書き換え が必要です。チップ製造メーカーに問い合わせ、LoRaWAN 用ファームウェアと各ユニット固有のID DevEUI を発行してもらいます。

チップファームウェアの更新は、専用基板を使った書き込み作業が一般的です。電子工学などの知識が必要で、難易度は高く、誰でも簡単にできるものではありません。
しかし、M5Stack と LoRa 無線ユニットを接続し、PC から USB Serial 接続することで簡単に書き込みができます。

この作業をするには予め M5Stack にチップ書き込み用ファームウェアを組み込む 必要がありますが、それだけでチップ書き込み専用機として活用できるのはマイコンの強みといったところでしょうか。チップ書き込み用ファームウェアは製造元であるマイアクリエイト社のサポートページで一般公開されているため導入もスムーズでした。

実際のファームウェア更新作業は STMicroelectronics 社が提供する STM32CubeProgrammer を利用します。
チップメーカー EASEL 社より提供いただいたファームウェアファイルを設定し、M5Stack を接続している USB Serial Port に接続し書き込みを開始します。この時に接続エラーや書き込み失敗するケースがあり、割とハマりやすいので以下に注意点を記載しておきます。

M5Stack の電源が入っていない
M5Stack ファームウェア書き込みアプリが適切に書き込まれていない（疎通ピンの指定が誤っている）
M5Stack ファームウェア書き込みアプリが Update モードになっていない
M5Stack ファームウェア書き込みアプリを入れてから電源OFF/ON（再起動ではない）をしていない（更新前のキャッシュが悪さをしている場合がある）
他ターミナル等から USB Serial Port に接続している

ファームウェアの書き込みが正常に終わると次の画面が表示されます。

M5Stack ファームウェアの組み込み

ここまでで、クラウド環境、Gateway 機器、LoRa無線ユニットの設定が全て完了しました。
ここからは、ULSA M5B で受信した風指標を LoRa 無線に乗せて飛ばす部分の組み込みです。

今回の構成としては M5Stack と ULSA M5B は M-BUS 接続し、LoRa 無線ユニットは GROVE 端子で接続します。
ここで１つ問題になるのは GROVE 端子に割り当て可能なポートが ULSA M5B 内蔵の I2C 9 軸姿勢センサーにつながっている点です。

弊社の風速計の設置場所は、正確な水平と方位を取り、物理的な工事で固定されています。風速計はクイックシューで簡単に取り付けが可能な状態です。
つまり 9 軸姿勢センサーは未使用なため、ファームウェア上で無効化し、UART に割り当てて通信することとしました。

以下は Arduino でシリアルポートを設定するコードの一部です。
M5Stack Core2 の UART は 3 系統あり、用途に応じてピンを割り当てます。

// USBシリアル用（PC）
#define BAUD_USB 115200
Serial.begin(BAUD_USB);

// UART1: I2C 9軸姿勢センサーは廃止して、GROVE ポートで利用する. PORT.A (GPIO33/32)など
#define BAUD_UART1 115200
#define UART1_RX 33
#define UART1_TX 32
Serial1.begin(BAUD_UART1, SERIAL_8N1, UART1_RX, UART1_TX);

// UART2: GPIO13/14
#define BAUD_UART2 115200
#define UART2_RX 13
#define UART2_TX 14
Serial2.begin(BAUD_UART2, SERIAL_8N1, UART2_RX, UART2_TX);

クラウド上で受信した値の検証

M5Stack から送信した指標値が正しくクラウドに届いているかを確認するため、AWS IoT Core の MQTT テストクライアントを使用します。送信先として指定している Topic をサブスクライブすることで、リアルタイムに受信された値を確認できます。

LoRaWAN を経由して送信したデータは、文字列・バイナリ形式問わず、BASE64 エンコードされた文字列として PayloadData フィールドに格納されます。
受信したデータを確認するには、まず BASE64 をデコードし、次に 16 進数表示へ変換します。

$ echo 'ARcAAwA/CQ==' | base64 --decode | hexdump -C
00000000  01 17 00 03 00 3f 09

得られた 16 進数データ 01 17 00 03 00 3f 09（7 バイト）を、固定長バイナリ形式の定義に従って little endian 形式で解釈します。解釈例は以下のとおりです。

項目	バイト位置	16進数値（little endian）	10進数変換	実数値（単位）
`nodeId`	1 バイト目	`01`	1	1
`windDirection`	2-3 バイト	`17 00` → `0x0017`	23	23°
`airSpeed`	4-5 バイト	`03 00` → `0x0003`	3	0.03 m/s
`virtualTemp`	6-7 バイト	`3f 09` → `0x093f`	2367	23.67 ℃

このように、固定長バイナリ形式で送信したデータを正しく受信・復号できることを確認し、風速計で取得した指標をクラウド上に送信する仕組みが正常に動作していることを検証できました。

実地検証

実際に競輪場に訪れ機器を設定して検証します。
競輪場屋内の最上階の窓際に LoRaWAN Gateway を設置し稼働させ、LoRa 無線ユニットに接続した風速計を数個持ちながらトラック周囲のフェンス外をぐるりと歩き回り検証します。

ここでは、電波の「強度」と「品質」を定量的に見るために、LoRa 無線ユニットが返す RSSI / SNR を確認しました（詳細は後述の「RSSI / SNR 目安値について」を参照）。

計測結果として SNR は 10 前後で推移しており、RSSI は -81 〜 -107 の範囲でした。
計測時は無観客であり電波影響がほぼ無いに等しい状況下でしたが、実際の本番で観客が超満員の時でも数値的にはあまり変わらず安定していたのは驚きでした。

これですべての計測位置で通信が確立でき、安定したデータ送信が可能なことを確認しました。送信間隔10秒での運用においても、電波干渉を回避し、安定した通信を実現できています。

RSSI / SNR 目安値について

RSSI（Received Signal Strength Indicator）は受信信号強度を表す指標で、値が 0 に近いほど強く受信できています（一般に負の値で表示され、より小さい値ほど弱い信号となります）。
SNR（Signal-to-Noise Ratio）は信号とノイズの比を表す指標で、値が高いほどノイズに埋もれにくく、安定して復調できる状態と言えます。

LoRaWAN における RSSI の解釈は、Wi-Fi などの一般的な無線通信とは異なる点に注意が必要です。

Wi-Fi では RSSI が -70 dBm を下回ると通信が不安定になりやすい傾向がありますが、LoRaWAN では -110 dBm 程度でも安定した通信が可能です。これは LoRa の拡散技術（Spreading Factor）により、ノイズ以下の微弱な信号でも復調できる特性があるためです。

また、電波通信は基本的に「確率」で成立するものであり、RSSI の値だけで通信可否を判断できません。
LoRaWAN では RSSI に加えて SNR（Signal-to-Noise Ratio）も重要です。SNR が良好なら、通信は成功しやすくなります。RSSI が低くても成立するケースがあります。逆に RSSI が高くても、SNR が悪い（ノイズが多い）環境では通信が不安定になる場合もあります。

「良い/悪い」の判断は、利用する周波数帯・Spreading Factor（SF）・帯域幅・端末/Gateway の受信感度などで変わります。ここでは LoRaWAN 運用でよく使われる大まかな目安を示します。

RSSI の目安（受信強度）

-60 dBm 以上: 非常に強い（超近距離）
-60 〜 -90 dBm: 強い（近距離〜見通しの良い環境）
-90 〜 -110 dBm: 実運用で十分狙える（屋外・遮蔽物ありでも成立しやすい）
-110 〜 -120 dBm: 弱めだが通信可能（SF/環境次第で成立することも多い）
-120 dBm 以下: かなり弱い、限界ギリギリ（パケットロスや不安定化が増えやすい）

SNR の目安（信号品質）

5 dB 以上: 非常に良好（ノイズの影響をほとんど受けず、安定した通信が可能）
0dB ～ +5dB: おおむね良好（安定しているが周囲のノイズが増えると影響を受ける可能性がある）
0dB ～ -10dB: 普通（許容範囲）。LoRa 特有の拡散技術によりノイズ以下の信号でも受信できる
-10 dB 未満: ノイズ優勢で限界に近い（安定運用の観点では要注意）

ハマったポイント

慣れない技術領域だったこともあり、検証中に大きく時間を費やしたポイントをまとめます。これから同様の構成で試す方の参考になれば幸いです。

LoRa モジュールの理解：通電中は接続状態が保持される

LoRa モジュール ES920LR3 を使った LoRaWAN 通信は、起動後に必要なパラメータを設定し、最後に start コマンドを Serial 経由で送り開始します。start 後は Join（OTAA）の完了を待つ状態に入り、基本的には 通電している間はその状態が維持 されます。

今回つまずいたのは、M5Stack の再起動ボタンが「電源断」ではなく「本体のリブート」である点でした。本体側だけが再起動しても、ES920LR3 側の状態が保持されているため、設定のやり直しや再 Join をしたつもりでも、実際にはチップが以前の状態のまま動き続けます。

起きたこと: 設定を変更したつもりでも挙動が変わらず、原因の切り分けに時間がかかった
対処: チップの状態を確実にリセットする（電源を落とす／電源断相当の手段を用意する）ことを運用・検証手順に含める

LoRaWAN の仕様理解：Join はすぐ完了するとは限らない

もう1つのポイントは、LoRaWAN の OTAA Join は「送ったらすぐ完了する」タイプの処理ではない、という点です。
OTAA Join では概ね図のような次の流れになります。

重要なのは RX1 / RX2 のタイミングで、Downlink は「Uplink の数秒後に開く短い受信ウィンドウ」に合わせて届く必要があります。周波数やデータレート（DR）などの条件が揃っていないと受信に失敗し、結果として Join の完了まで 30 秒〜数分かかることもあります。

Wi-Fi のように「数秒で接続が確立する」体験に慣れていると、Join が 1 分程度かかるだけで「何かが壊れている」と判断しがちです。実際には正常系でも待ちが発生し得るため、検証時は一定時間待つ／リトライ間隔を含めて設計する／ログで Join の進行状況を追えるようにする、といった前提で進めるのが安全でした。

まとめ

LoRaWAN の導入により、競輪場での風可視化システムにおける通信の安定性を改善できました。送信間隔は 10 秒に制限される一方で、観客がいる環境でも電波干渉の影響を受けにくくし、安定したデータ収集につなげられています。

本記事で紹介した主なポイントは以下のとおりです。

通信技術の選定: 実装コストと機器調達の手軽さから LoRaWAN を採用
データ形式の最適化: JSON から固定長バイナリ形式への変更により、AirTime を大幅に削減し電波法適合性を確保
送信頻度の設計: AirTime 計算に基づき、送信間隔 10 秒という現実的な設計を実現
実地検証: 平塚競輪場での検証により、すべての計測位置で安定した通信を確認

LoRaWAN を用いたシステム設計では、送信データ形式の選択そのものが電波法適合性とシステム健全性を左右するという点を強く意識する必要があります。
当初は「通信方式を少し変えるだけで実現できる」と見積もっていましたが、実際には LoRaWAN の仕様に寄り添った設計（AirTime・Join・Downlink の制約を前提にした設計）が特に重要でした。

まだ改善の余地はあるため、今後も更なるアップデートを楽しみにしていてください。

参考資料

TSKaigi Hokuriku 2025参加レポート