1 概要
このドキュメントでは、主に、ハードウェア仕様、ソフトウェア仕様、設計・製造等における必要事項などの技術要件や制約などを説明しています。
1.1 はじめに#
本920MHz LoRa省電力ワイヤレスモジュールは、電波の送受信を行うためのモデム・無線部と、その制御や設計者へのデジタル通信機能を提供する制御ソフトウェアであるファームウェアを搭載した省電力マイクロコントローラーで構成されています。また、それらに安定した電力を供給するための電源回路を内包しています。
E220-900T22S(JP)
E220-900T22S(JP)は、LoRaワイヤレスの新世代モジュールであるSEMTEC社LLCC68チップを採用し、UARTシリアル通信インタフェースを提供する通信モジュールです。このモジュールは、LoRaワイヤレス伝送の多様な方式とパラメータをサポートし、周波数920.6〜928.0MHzの920MHz帯アンライセンスバンドを使用し、LoRaスペクトラム拡散技術によって動作します。標準的な電源構成において、TTLレベル出力は、3.3V I/Oポートの信号電圧と互換性があります。
E220-900T22S(JP)は、この新世代のLoRaモデムチップの採用によって、従来のSX1276ソリューションと比較して 伝送距離が長く、高ビットレートで、消費電力が低く抑えられているのが特徴です。
また、Wake on Radio(WOR: 無線によるウェイクアップ)、Carrier Monitoring(キャリアモニタリング、キャリアセンス)、Communication Key(通信暗号キー)などの機能をサポートし、Sub-Packet Length(サブパケットの長さ)設定などをサポートします。本製品は日本国内でアンライセンスでの利用が許可された920MHz帯の広い周波数範囲をカバーすることができます。
1.2 機能#
本モジュールの代表的な機能概略を列挙します。一般的な同種のモジュールに搭載されている機能の他、本モジュール固有の機能も含みます。各機能の詳細については、本ドキュメントの詳細記述を確認してくだい。対応ファームウェアバージョンが付記されている機能は、そのファームウェアバージョンで利用可能になった機能です。
LLCC68チップソリューションの採用で低消費電力、高速、長距離に対応
920MHz Private LoRa方式 (他社・他種のPrivate LoRa、LoRaWANとの相互通信・互換性はありません)
理想的な条件下では通信可能距離は5km以上
送信電力はソフトウェアから調整可能
パケットあたり最大200バイトのペイロードを使用可能
ソフトウェアの開発者や利用者自身でCommunication Key(通信暗号キー)を設定可能
通信暗号キーは読み取ることができず、LoRa通信における通信の機密性の向上に寄与
信号品質の評価、通信ネットワークの改善、および測距のためのRSSI信号強度インジケータ機能をサポート
バッテリー駆動のアプリケーションに適した、Wake on Radio(WOR : 無線によるウェイクアップ)をサポートし超低消費電力機能を提供
固定デバイス宛送信、ブロードキャスト送信、チャネル監視をサポート
日本国内でのISM 920MHz周波数帯域をサポート
最大送信電力は13dBm(約20mW)
設定パラメータは電源オフ後、不揮発メモリに保持され、モジュールは電源投入後に、その保持されているパラメータに従って動作
効率的なウォッチドッグ設計で、万一の例外の発生時には、モジュールは自動的に再起動し、以前のパラメータ設定に従って継続動作
DeepSleepによる待機、送信、受信待受、省電力ＷＯＲ受信待受のモードセレクタ
1.7K〜62.5kbpsのデータ伝送レートをサポート(連続送信時には電波法の制約で低下)
標準給電手順では、3.1〜5.5V(3.5V以上推奨)のDC電源をサポート
内蔵LDOの余剰電力を設計者の機器に供給して省電力化
低電圧給電手順の使用で2.2〜3.6V (2.9V以上推奨) DC電源に対応 [ver.1.2のみ]
業界標準設計の、-40〜+85℃環境下での長期使用をサポート
アンテナ端子はIPEX接続と設計者によるPCB引き出しでの使用を選択可能
パッケージは小型で手はんだ、量産リフローに対応
1.3 アプリケーション#
E220-900T22x(JP)シリーズは、シリーズモデルである、22Sと22Lで相互通信も実現でき、アプリケーションの幅を拡大します。
ホームセキュリティアラーム、リモートキーレスエントリー
スマートホームおよび産業用センサー
ワイヤレスアラームセキュリティシステム
ビルディングオートメーションソリューション
ワイヤレス産業グレードリモートコントロール
ヘルスケア製品
高度な検針アーキテクチャ（AMI）
産業向けアプリケーション
農林水産業向けフィールドアプリケーション
研究ラボ計測機器
ウェアラブルデバイス
1.4 アプリケーションのトポロジーや電力コントロール#
Private LoRaにおけるトポロジー（通信ノードの通信パターンの組み合わせ方など）は、LoRaWANなどと比較して自由度が高く、LoRaWANでは実現できないアプリケーションを実現できる可能性があります。 また、LoRaWANのような、インターネットを介してクラウドサーバーへデータを集約するような使用方法を想定する場合は、このPrivate LoRaからIP通信へのゲートウェイ（LoRa – IP Gateway、アクセスポイント）を設置・使用して、中継が必要です。
本通信モジュールに、特段の目的を区別する機能やモジュールの区別はなく、コンフィグレーション機能からの設定と、アプリケーションの実装によって、振る舞いを任意に実装できます。
Private LoRaよく使用されるトポロジーには。以下のようなものがあります。
- アクセスポイント／ゲートウェイ
図 1はアクセスポイント／ゲートウェイ型のネットワークトポロジーの概略を示しています。ゲートウェイが中心となり複数のアクセスポイントと接続しています。各アクセスポイントには複数のデバイスを接続することが可能で、それぞれのデバイスはアクセスポイントを通じてインターネットにデータを送信します。アクセスポイントとゲートウェイ間は、LoRa通信、それ以外の通信方式を使用することが可能です。また、アクセスポイントを省略したデバイスが直接ゲートウェイへ接続するパターンが実際にはより多く使用されます。
図 1 アクセスポイント／ゲートウェイ
- マルチアクセスポイント／ローミング
図 2はマルチアクセスポイント／ローミング型のネットワークトポロジーを表現しています。複数のアクセスポイントが同一のゲートウェイに接続されており、同じネットワークを形成しています。ローミングデバイスは点線で各アクセスポイントに通信が可能で、これはデバイスがアクセスポイント間を自由に移動できることを示しています。この構成により、デバイスは広い範囲でデータ送達パスを確保しながらアクセスポイントのカバレッジエリア内を移動することができます。このとき、本Private LoRa等では、デバイスは送信先であるアクセスポイントを（位置情報などから）明示的に指定するか、すべてのアクセスポイントでデバイスからの送信パケットを受信できるように設計する必要があります。
図 2 マルチアクセスポイント／ローミング
マルチホップ／中継伝送／メッシュ
図 3はマルチホップ／中継伝送／メッシュ型のネットワークトポロジーを表現しています。各ノードは複数の他のノードと接続されており、メッシュ構造を形成しています。ノード間の接続は双方向で、データの送受信が可能です。直接的な接続がないノード間でも、中間ノードを経由してデータ伝送が行われます。このトポロジーの利点として、以下があります。- 冗長性：複数の経路が存在するため一部のノードが故障しても通信が維持される
- 拡張性：新しいノードを容易に追加できる
- 自己修復：ネットワークは動的に最適な経路を見つけることができる
- 広いカバレッジ：直接通信できない遠距離のノード間でも通信が可能となる
図 3 マルチホップ／中継伝送／メッシュ
このようなメッシュ型マルチホップを行う場合は、本Private LoRaモジュールにおいては、アプリケーションによる実装にて、マルチホップメカニズムを実装する必要があります。
- 一斉配信／制御／同期／ビーコン
図 4は一斉配信／制御／同期／ビーコン型のネットワークトポロジーを表現しています。中央コントローラーから各ノードへの一斉配信を表しています。これは制御コマンドや更新情報の配信などに使用されます。また、ビーコン送信は各ノードが定期的に送信するビーコン信号を表しています。これはノードの存在を知らせたり、通信のタイミングを維持したりするために使用できます。
図 4 一斉配信／制御／同期／ビーコン
Private LoRa方式では、通信の長距離到達性を利用して、このような使用方法が比較的広いエリアに適用可能です。また、中央コントローラーを受信専用で使用する場合で、一切送信処理を行わないようにした場合は、受信専用アンテナとして、電波法の規定を無視できる場合もあります。
- ピア・ツー・ピア型
図 5は、ピア・ツー・ピア（P2P）型のネットワークトポロジーを表現しています。各アプリケーションの機能は、各ピア（LoRaデバイス）に分散しており、中央サーバーを介せず全てのピアが対等な立場で通信を行います。
図 5 ピア・ツー・ピア型
このトポロジーは、Private LoRa方式における特有の使用方法として、通信インフラが脆弱な僻地や、通信インフラの空白地帯において、デバイス間での自律通信を成立させたい場合に使用される方法です。インターネットへのデータ伝送はできませんが、互いの位置関係を把握するなど、ワイヤレス通信でのアドホックな閉域網として機能させる場合、本モジュールでは簡便に実装できるため好まれます。
1.5 ファームウェアver.1.0 / ver.1.5の違い#
ファームウェア ver.1.0とver.1.5は互換性に配慮した、高機能かつアプリケーションやハードウェアの堅牢性を強化する目的で設計されたファームウェアです。 ver.1.x搭載のモジュールはver.2.0へ変更することはできません。
ver.1.2は、ver.1.0に低電圧動作モード切り替え機能を提供し、より低い電圧での動作継続を行えるよう改良されたファームウェアです。
現在、製品モデル毎のファームウェアバージョンのサポートは、次の通りです。
- E220-900T22S(JP) firmware ver.1.0, ver.1.5
ver.1.5における変更点は以下のとおりです。
低電圧動作モード切り替え機能
ver.1.5においては、給電電圧レベルを低圧方向へ拡大し、低電圧給電専用端子から、（UVLO無効設定時）最低2.1V程度まで動作させることが可能となりました。モジュール全体の要求電源電圧は、2.1〜5.5Vと広いレンジで対応でき、3.7V系バッテリー（3.0-4.2V程度）、乾電池や乾電池タイプの二次電池（2本直列時、2.1〜3.4V程度）、コイン・ボタン電池（CR系2.9〜3.1V程度）USB VBUS+5V給電、多くのマイコンで使用される3.3Vや2.8Vなどと直結でき、可変電圧レベルにも各給電端子電圧の対応範囲で許容できるため、一般的な設計における外挿の電圧レギュレータを省略することも可能となり、バッテリーや機器の小型化を可能とします。本ドキュメント提供時点より、VDD端子からの低圧給電ピンの利用を公式にサポートします。旧来の、VCC端子（上限5.5V）と排他的に給電ピントして利用することが可能です。
キャリアセンスのタイムアウト機能
送信時に強い電波干渉がある場合、キャリアセンスが継続し、正常な状態に戻らない問題を改善しました。キャリアセンスの継続時間に5秒のタイムアウトを設け、キャリアセンス待機状態が持続しないようにしました。タイムアウトが発生した場合、該当の送信パケットは破棄されます。
送信結果判定用フラグの追加
送信時、AUXピンがHighに戻った際に、送信が成功したか否かをユーザープログラムで判別できるよう、タイムアウト発生を示すフラグを追加しました。また、このフラグの状態を取得できる専用コマンドを実装しました。
上記の改修内容を含む詳細については、ファームウェアver1.5までの改修点をまとめた差分ドキュメントをご参照ください。
1.6 ファームウェアver.2.0使用時の本ドキュメントの利用#
本ドキュメントは、ファームウェアver.1.0、および、ver.1.5を対象に記載されています。
ver.2.0を使用する場合は、原則として、ver.2.0のドキュメントを参照してください。
ただし、以下の条件を前提として本ドキュメントをver.2.0における、ver.1.0/1.2互換機能の利用向けとして、使用することは可能です。ver.2.0で強化された高度な機能を無視して、簡易的に、ver.1.0/1.2の機能を確認する場合などの使用方法としては問題ありません。
ver.1.0/1.2のデフォルト設定の差を吸収すること
0x09レジスタのbit 6を操作することで、ver.1.0/1.2のデフォルトと揃えることが可能です。トランスペアレント送信モードを使用することが前提の場合は、これは無視してかまいません。ver.1.0/1.2で作成されたアプリケーションをver.2.0モジュールで使用する場合には、モジュール内部のバッファの振る舞いが異なることに起因するAUXピンの信号タイミング等が若干ずれることを許容するようにしてください。通常の割り込みや十分に余裕のある堅牢なタイミング制御がされている場合は問題になることは無いと思われますが、僅かなAUX信号や、RXDからの受信タイミングなどの変化が許容できない実装がされているアプリケーションでは、アプリケーションの実行時間や効率性などに影響が生じる場合があります。
トランスペアレント送信モード使用時の挙動が、内部バッファのサイズの影響で送信データの量によって、若干変化する可能性があります。トランスペアレント送信モードを利用時は、このパケット区切りなどの影響が生じないアプリケーションでの使用方法を想定、もしくは、採用すべきですが、そうで無い場合、アプリケーションの挙動が変化する可能性があります。
トランスペアレント送信モードを使用せず、通常（Fixed-block）送信モードを使用することで、ver.2.0でのve.1.x互換モードでの動作とver.1.0/1.2の機能的な振る舞いは上記以外の点においては同一と見做すことが可能です。