0

私は readstream インターフェイスを使用して 100hz でサンプリングしています。インターフェイスをオシロスコープ アプリケーションに統合することができました。送信するパケットにバッファ値を渡す方法に疑問があります。現在、これは私がやっている方法です:

uint8_t i=0;

イベント void ReadStream.bufferDone( error_t 結果、uint16_t* バッファー、uint16_t カウント)

 {
 if (reading < count  ) 
 i++;
 local.readings[reading++] = buffer[i];
 }

バッファ サイズを 50 に定義しましたが、Nreadings=2 に設定しているにもかかわらず、パケットごとに 1 つのサンプルしかないことに気付いているため、これが正しい方法かどうかわかりません。また、チェックすると、サンプリングレートは100サンプル/秒ではないようです。送信するパケットにデータを渡す方法が正しくありません。

4

1 に答える 1

0

あなたの質問とコメントに従って、いくつかのことを明確にする必要があると思います。

micaZ モートの加速度計からの単一サンプルの読み取りは、次のように機能します。

  1. 加速度計をオンにします。
  2. 17 ミリ秒待ちます。ADXL202E (加速度計) のデータシートによると、起動時間は 16.3 ms です。これは、この特定のハードウェアが、電源を入れた直後ではなく、ある程度の遅延を経て最初の読み取りを提供できるためです。この遅延を小さくすると、誤った読み取り値が得られる可能性が高くなりますが、動作は定義されていないため、正しい読み取り値が得られる場合や、結果が周囲温度などの環境条件に依存する場合があります。この 17 ミリ秒の遅延をより低い値に変更することは、確かに悪い考えです。
  3. 加速度計のアナログ出力電圧をデジタル値 (整数) に変換する MCU コンポーネントであるアナログ デジタル コンバーター (ADC) から (2 つの軸で) 値を読み取ります。ADC がサンプリングできる速度は、加速度計のパラメーターとは無関係です。これは別のハードウェアです。
  4. 加速度計をオフにします。

コードを呼び出すと、このようRead.read()になります。サンプリングできる最大頻度は 17 ミリ秒ごとに 1 回、つまり 1 秒あたり 58 サンプルであることがわかります。MCU からのオーバーヘッドやタイマーの不正確さのために、それはさらに少し小さいかもしれません。Read.read()これは、ループまたは固定間隔ごとに呼び出してサンプリングする場合に当てはまります。これは、この呼び出し自体が 17 ミリ秒以上続くためです (コマンドとイベントの間の遅延を意味します)。

あなたがしたいことは次のとおりです。

  1. 加速度計をオンにします。
  2. 17 ミリ秒待ちます。
  3. 一連の読み取りを実行します。
  4. 加速度計をオフにします。

これを行うと、サンプルごとの遅延ではなく、一連のサンプルに対して 17 ミリ秒の遅延が発生します。重要なことは、これらの手順は、読み取りを実行するために使用するインターフェイスとは関係ありません. アプリケーションで複数回呼び出すことができますが、この加速度計に対して既に実装されているコマンドRead.read()の実装と同じにすることはできません。readこれは、既存の実装が加速度計のオンとオフの切り替えを担当し、それぞれを読み取る前に 17 ミリ秒待機するためです。サンプル。便宜上、ReadStream代わりにインターフェイスを実装し、アプリケーションで一度呼び出すことができます。

ReadStreamさらに、マイクロ秒のタイマーを使用し、ADC の 17 ミリ秒の整定時間とは無関係であると書いています。その文は完全に間違っています。まず第一に、インターフェイスがタイマーを使用する、または使用しないとは言えません。インターフェイスは、コマンドとイベントのセットであり、定義はありません。インターフェイスの特定の実装では、タイマーを使用する場合があります。ReadおよびインターフェイスはReadStream、加速度計、温度計、湿度計、磁力計などのさまざまなハードウェア コンポーネントによって、さまざまなプラットフォームに複数回実装できます。次に、17 ミリ秒のセトリング タイムは、ADC ではなく加速度計を指します。また、使用するインターフェイスReadやReadStream、ドライバーが使用するタイマー (ミリ秒またはマイクロ秒) に関係なく、加速度計の電源を入れた後は、常に 17 ミリ秒の遅延が必要です。前述したように、この遅延は、1 回の読み取りごとではなく、複数回の読み取りごとに 1 回行う必要があります。

TinyOS のソース コードには、ReadStream継続的にサンプリングできるインターフェイスを提供する加速度計ドライバーの実装が既に含まれているようです。AccelXStreamCおよびAccelYStreamCコンポーネント ( tos/sensorboards/mts300/ 内)を確認します。

ReadStreamインターフェイスは 2 つのコマンドで構成されます。postBuffer(val_t *buf, uint16_t count)サンプル用のバッファを提供するために呼び出されます。加速度計ドライバーでval_tは、 として定義されていuint16_tます。複数のバッファを 1 つずつ投稿できます。このコマンドは、バッファのサンプリングと充填をまだ開始していません。その目的のために、指定された期間(マイクロ秒単位) でサンプリングすることにより、デバイスにバッファーの書き込みを開始するように指示read(uint32_t usPeriod)するコマンドがあります。バッファーがいっぱいになると、イベントが発生し、コンポーネントが次のバッファー (存在する場合) への書き込みを開始します。バッファが残っていない場合は、追加で event を取得します。これはアプリケーションにパラメータを渡します。このパラメータは、実際のサンプリング期間を示し、呼び出し時に要求した期間とは異なる (特に、より高い) 場合があります。bufferDone(error_t result, val_t *buf, uint16_t count)readDone(error_t result, uint32_t usActualPeriod)usActualPeriodreadいくつかのハードウェアの制約のため。

したがって、解決策は、and (またはそれらを使用するいくつかの上位レベルのコンポーネント)ReadStreamによって提供されるインターフェイスを使用し、期待される期間をマイクロ秒単位でコマンドに渡すことです。実際の周期が予想よりも低い場合は、ハードウェアの制約または ADC ドライバーに実装されていないために、より高いレートでのサンプリングが不可能であることを意味します。2 番目のケースでは、ドライバの修正を試みることができますが、低レベルのプログラミングに関する十分な知識が必要です。このプラットフォームの ADC ドライバーのソース コードは、tos/chips/atm128/adcにあります。AccelXStreamCAccelYStreamCread

于 2015-04-12T13:04:16.390 に答える