DigiによるとXBee3モジュールでMicroPythonを用いたADCデータのサンプリングを行う場合、最小サンプリング幅は約128msが推奨されています。これは、モジュール内部の処理やタイミング制約、MicroPythonの実行オーバーヘッド、ADC自体の変換時間などが影響しています。さらに、XBee3は通信や電源管理など複数のタスクを同時に処理するため、システムリソースが分散され、サンプリング速度にも影響を及ぼします。また、サンプリングレートの上昇は消費電力を増加させるため、バッテリー駆動環境では128msという間隔が電力管理上も適しています。ハードウェアとファームウェア設計上の制約も含め、信頼性と安定性を重視した結果、このような仕様となっています。
以下にADCのビット数とサンプリング間隔の最小値についてまとめます。
| ADC | サンプリング間隔の最小値 | |
| IR(I/O Scanning Rate)によるフレームの送信 | 10ビット | 50ms |
| MicroPython | 12ビット | 128ms（推奨値） 25ms（実績） |
Configurationの中のI/O Samplingの中のIR IO Scanning Rateにより送信IOサンプリングレートを設定すると、定期的なサンプリングが有効になります。50ms以上の値に設定すると、有効なすべてのデジタルIOおよびアナログ入力が設定された時間毎にサンプリングされて送信されます。IOサンプルは、DH+DLで指定されたアドレスに送信されます
Digiが提示する128msは、サンプリング精度や安定性及びタイミングずれを考慮した「仕様上の最小サンプリング間隔」であり、ハードウェアやファームウェアの仕様上の限界ではないということが分かります。
25ms間隔でのサンプリングが可能になった理由として、主に以下の2点が挙げられます。
① MicroPythonによるローカル処理により、Zigbeeスタックの制約を回避できた点
Zigbeeを介してADCデータを送信する場合、送信待ちやフレーム処理などの通信関連のオーバーヘッドが大きく、これがサンプリング周期の短縮を妨げる要因となっていました。しかし、MicroPythonを用いて adc.read() によりデバイス内部でADC値を取得し、ローカル処理のみに限定した場合、Zigbeeスタックの影響を受けず、これらの通信オーバーヘッドを完全に排除できます。特に、from machine import ADC による読み取り処理は非常に軽量で、高速に実行可能であるため、より短い周期での安定したサンプリングが実現可能となります。
② ADCハードウェアとしての性能が十分に高い点
XBee3に内蔵されているADCは、TI製のマイコン（例：CC2652）をベースとしており、ハードウェアとしては数十kHz〜数百kHzでのサンプリングが可能な設計です。したがって、25ms（＝40Hz）というサンプリング周期は、ADCの性能面から見ても十分余裕があると考えられます。
結論としては、性能を追求するのであればADCの分解能も12ビットと高く、高時間分解能でサンプリングが可能なMicroPythonを用いる方法を選択すべきことが分かります。但し、低分解能でも問題なければ簡便にIR(I/O Scanning Rate)によるにフレーム生成が可能です。