LoRaモジュールは各社各様、P2Pは全然共通じゃない話
この記事について
💡この記事は、「LoRaモジュール」と一言で言っても、メーカーごとのP2P通信(独自モード)は仕様がバラバラで互換性がない ということをお伝えする記事です。
LRA1同士では問題なく通信できますが、他社モジュールとは原則として通信できません。
※LoRaWANモードを除きます。
LoRa対応モジュールって、たくさんのメーカーから出ていて、
設定項目も似てるし、なんとなく「どれも同じように使えそう」と思ってしまいがちです。
今回は、あるお客様からの問い合わせをきっかけに、よくある誤解と実情についてまとめてみました。
🎀 LoRaって書いてあるからって、仲良く通信できるとは限らないんだよ〜!
名前が似てても、中身は別モノです
最近、他社製のLoRaモジュールをお使いのお客様から、
💭「今の設定と同じように、LRA1でも動かせますか?」
というご相談がありました。
たとえば、他社のLoRaモジュールでよく使われている:
- PAN-ID
- SRC-ID
- DST-ID
といった項目。
確かに、LRA1 にも
- GID(グループID)
- OWN(自局ID)
- DST (宛先ID)
といった、似たような働きをする設定 があります。
ですが、これは機能的に近いからたまたま似た名前を付けているだけであって、
中身はまったく別モノです。
これらの、設定値の意味付けも異なります。
たとえば、LRA1の DST の場合
– LRA1では DST=65535 はブロードキャストです
– 他社のLoRaモジュールでは、似た名前/機能の DST-ID があります
– DST-ID は 65535 に設定可能か?
– 設定できたとして、それがブロードキャストとして機能するのか?
– LRA1と他社のLoRaモジュールで、ブロードキャストの意味が同じか?
という具合に、すべての設定項目について当てはまります。
🎀 “名前が同じ=仕様も同じ”って思っちゃうのは、ちょっと危ないよ〜!
LoRaで共通しているのは“電波の出しかた”だけ
LoRaという通信方式で共通しているのは、以下のような物理的なパラメータです:
項目 | 内容 |
---|---|
CH (Channel) | 周波数 |
SF(Spreading Factor) | 拡散率 |
BW(Bandwidth) | 帯域幅 |
CR(Coding Rate) | 誤り訂正 |
PWR(Power) | 送信出力(モジュール依存) |
これらはLoRaの物理層として共通で使われる設定なので、モジュール間である程度互換性があります。
また、他社のLoRaモジュールでは SF(拡散率)のoptimize(最適化)で、ON/OFFが設定できるものがあります。
しかし、LRA1では、SF/BW/CRの組み合わせに応じて、自動的 にSemtech推奨のoptimizeが設定されるため、その設定がありません。
🎀 常にチップメーカーの推奨状態に設定されてるってことなんだよ〜!
CH・SF・BW・CR 以外でも、物理層扱いの、プリアンブルの長さ、IQの極性、SyncWord などの設定が異なれば、
お互いに通信はできなくなります。
でも、多くのモジュールではこれらの設定は固定値で、共通な値ではありません。
🎀 ちょっとの違いでも“ぜんぜん通じない”…LoRaって繊細なんだよ〜!
それ以外の部分では、たとえば:
- アドレスやIDの構造
- ACKの仕組み
- 再送・中継の方法
- スリープとウェイクアップの制御
- パケット構造やコマンド体系
- シーケンスNoなどの付加情報
といったものは、すべて各社が独自に設計している部分 です。
🎀 みんな自由に作ってて、バラバラなんだよ〜!
似てるのは、目的が同じだから
LoRaモジュールって、どの製品も目指しているところはだいたい同じです:
- センサーからのデータを
- 低速でもいいから
- 省電力で
- 遠くまで飛ばしたい!
この条件で設計していくと、だいたいこうなります:
- UARTで制御する(マイコンとつなぎやすい)
- 送信元や宛先を識別するIDがほしくなる
- ACKや再送の制御も入れたくなる
- スリープとウェイクアップをどうにかしたくなる
…つまり、目的が似てるから構成も似ちゃうのは自然な流れなんです。
🎀 “似てる”のはパクリじゃなくて、必要に迫られてそうなるだけなんだよ〜!
でも、内部構造やパケットの中身はそれぞれ別物なので、安易に「互換あるでしょ?」と思って使うと通信できなくて困ることになります。
それでも、見た目が似てるのにはワケがある
それでも、
実際の現場では、こういうこともあります:
「A社とB社のモジュール、設定がそっくりで通信できた。LoRaって共通なんだね!」
ときどき、設定項目や挙動がそっくりなLoRaモジュールに出会うことがあります。
OEM/ODMというものもあるので、その場合は同じ中身なので当然なのですが、
ただの偶然じゃなくて…
「実は、もともと同じ会社にいた技術者が作った」
「中の設計者が、以前の設計をベースにしている」
という “業界あるある”な背景 があるケースも珍しくありません。
🎀 モジュールは違っても、作った人が同じだったら…そりゃ似るよね〜!
つまり、LoRaの規格が共通だから通信できたわけではないんです。
LoRaWANだけが共通仕様です
LoRaの世界で、上位層まできっちり共通ルールが定められているのが LoRaWAN です。
LoRaWANでは:
- 物理層の設定
- アドレスの形式
- 認証方法(OTAA/ABP)
- ゲートウェイとの通信手順
などがすべて仕様化されており、異なるメーカーのモジュールでも相互通信が可能です。
LRA1も、LoRaWAN Class A / Class C に対応しています。
LoRaWANネットワーク上であれば、他社ゲートウェイとも連携可能です。
🎀 でもLoRaWANって、端末同士では直接やりとりできないんだよ〜。ちょっと不便かも?
P2P通信では「互換」は期待しない方がいい
LoRaモジュール単体で使う P2Pモード(モジュール間の直接通信) では、
各社完全に独自実装です。
- LRA1の独自プロトコル
- 他社の独自プロトコル
どれもバラバラで、原則として相互通信はできません。
設定項目が似ていても、仕様もパケット構造も別です。
また、モジュールの制御方式の異なります。
LRA1では、BASICを使用してユーザーが様々なプログラムを組んで動作を定義することができますが、
多くの他社モジュールでは、特定の設定項目から機能や動作を選択するようになっていますので、
設定項目そのものがお互いに共通ではありません。
ただし、どちらが優れているとかそういう事ではなく、目指すものが違うってことです。
🎀 みんな違って、それがいい!ってことだねえ~!
まとめ
- 「LoRa対応=設定互換」は 誤解
- 名前が似てても、仕様も数値の意味も別物
- 通信できたのは、たまたまか、出元が同じだっただけかも
- 相互通信を前提にするなら、LoRaWANでの構築が必要
🎀 “似てるからいけるでしょ?”って思ったら…痛い目みちゃうかも〜!
📪 お問い合わせなど
技術的なご相談やご質問などありましたら、
📩お問い合わせフォーム
または、
📮info@shachi-lab.com までお気軽にどうぞ。
🎀 他社モジュールからの乗り換え、ぜんぜんOKだよ〜!互換がなくても置きかえの方法はあるから、お問合せしてねっ!
🔗 関連リンク
しゃちらぼの最新情報や開発の様子は、こちらでも発信しています:
- 🌐しゃちらぼ公式サイト
- 🐦 X(旧Twitter):@shachi_lab
- 📗 Qiita:@shachi-lab
- 🐙 GitHub:@shachi-lab
- 📸 Instagram:@shachi_lab
ほんとは「しゃちらぼ(Shachi-lab)」なんだけど、見つけてくれてありがとう🐬
コメント