nRF5340 で OpenThread を使って、省電力要件を維持しつつ、待機時の応答時間を向上させた話。

概要

下記記事の続き。

前回の調査では、待機時電流のアヴェレージが 100uA未満という条件下にて、ESP32 ＆ ESPNOW での待機時の通信周期は、約90秒が限界だったが、流石に NG が出たので再調査を行うことになった。

たどり着いたのは、OpenThread。

ZIP圧縮されたファイルを解凍する必要があったので、
メモリの少ないnRF52系は選択肢から外れて、nRF5340 で検証した。

結論としては、

OpenThreadはゲートウェイとエンドデバイス間のUDP通信のデータレートが5KiB/s程度だが、8秒周期でゲートウェイとエンドデバイス間通信を実現できることがわかった。

単体構成だと、50KiBのZIP圧縮されたファイルの転送時間が１０秒程度、ZIP解凍する時間が２秒程度かかる。

通信速度の速いデバイスの電源スイッチとして利用するか、単体で全て処理するかの結論はまだ出ていないが、90秒から８秒まで、レイテンシーが向上したのは一つの成果と考えられる。

使用機材（電子ペーパー）

電子ペーパー周りは前回と同じく WaveShare のデバイスを利用した。
パワーMOSFETをつかって、エンドデバイスから電源管理を行った。

使用機材（エンドデバイス）

エンドデバイスは、技適のある RAYTAC MDBT53V-DB（もしくはMDBT53-DB） を使用。
オンメモリでは処理できないので QSPI-NOR フラッシュメモリを外付けした。
（SPI接続でも試してみたが、QSPI接続にくらべZIP解凍時間が６倍くらい遅くなったので QSPIを採用した）

nRF53とnRF53vの違いは、チップの大きさとGPIOの数。
53vは小型化されている分GPIOが少ない。

使用機材（ゲートウェイ）

ゲートウェイは、 RAYTAC MDBT53V-DB（もしくはMDBT53-DB）に OLIMEX ESP32-ISO を UART接続した。

Openthread と Ethernetを共存させると、Ethernetが正常に動作してくれなかったため、
サーバサイドの通信は、UARTを介して行うことにした。

※ nRF5340 単体で Openthread と Ethernet を共存できるかについては調査が完了していない。

使用機材（サーバー）

ゲートウェイとエンドデバイス間の調査が目的だったので、
今回は、Ethernet で LinuxPC（Debian）に接続してサクッとテストを行った。
サーバーサイドは Node-red を利用した。

以上。