2

Contiki-OS が UDP パケットを送信するとき、Contiki-OS 内で何が起こっているのか説明してもらえますか?

CC2538 チップで動作する私のデバイスの消費電流の詳細は次のとおりです。

CC2538 消費電流

私の質問は、理論的には 250kbps で 408 ビット長のパケットが約 2ms で送信されるはずなのに、UDP ブロードキャスト パケット (約 250ms) を送信するのになぜそんなに時間がかかるのですか? 送信が最後に 10 ミリ秒と言えるかどうかはわかりますが、ここでは違いが非常に大きくなります。

の例を使用します contiki/examples/ipv6/simple-udp-rpl/broadcast-example.c

誰にもアイデアはありますか？

4

2 に答える 2

3

デフォルトでは、Contiki は ContikiMAC Radio Duty Cycling (RDC) プロトコルを使用します。プロトコルは、2 つの相反する要件に対処する必要があります。受信するパケットがない場合、受信ノードをほぼ常にスリープ状態にすると同時に、可能な限り確実にデータを配信できるようにする必要があります。ContikiMAC で採用されているソリューションは、送信機に負担をかけることです。レシーバーが無線チャネルを 1 秒あたり 8 回チェックする場合 (cc2538dk プラットフォームのデフォルト設定)、トランスミッターは、レシーバーがウェイクアップしてパケットを認識したことを確認するために、少なくとも 125 ミリ秒の間送信する必要があります。実際には、これは、パケットが連続して複数回再送信されることを意味します。詳細な説明については、ContikiMAC の論文とContiki のドキュメントを参照してください。

そうは言っても、最大期間の送信が常に表示されるとは限りません。ユニキャストの場合、受信者は通常、受信が成功した後に ACK を送信します。送信機はこの ACK をチェックし、受信した場合は送信を停止します。このようにして、必要な送信の予想平均数は 2 分の 1 に削減されます。そして、フェーズ最適化もあります。これにより、送信者は送信の開始を受信者の予想されるウェイクアップ時間と同期させることができます。ただし、ブロードキャストの場合、ACK は生成されず、フェーズの最適化は機能しません。

予想外に長い送信のもう 1 つの考えられる理由は、CCA チェックの失敗です。パケットを送信する前に、無線スタックはまずメディアが空いているかどうかをチェックします。そうでない場合は、しばらくバックアップしてから再試行します。

于 2014-10-03T18:30:47.723 に答える
1

問題が見つかりました: パケットの送信後、無線が適切にオフにされません。

transmit()ファイル内の関数の最後で、cpu/cc2538/dev/cc2538-rf.c以前にオフになっていた場合にのみ、ラジオがオフになります。

if(rf_flags & WAS_OFF) {
    rf_flags &= ~WAS_OFF;
    off();
}

しかし実際には、プログラムがこの状態になることはなく、パケットの送信直後にラジオがオフになることはありません。

この問題は、関数channel_clear()(関数の開始時に呼び出されるtransmit()) が最初にこのフラグをクリアするために発生します。したがって、関数transmit()は実行前に無線がオフだったことを認識できなくなり、無線がオンのままになります。

channel_clear()この問題を解決するために、ラジオをオフにし、関数自体の内部でオンになっている場合にのみフラグをクリアするローカル変数を内部に配置しました。

static int
channel_clear(void)
{
  int cca;
  /* Fix: local variable */
  uint8_t intern_onoff;

  intern_onoff = 0;

  PRINTF("RF: CCA\n");

  /* If we are off, turn on first */
  if((REG(RFCORE_XREG_FSMSTAT0) & RFCORE_XREG_FSMSTAT0_FSM_FFCTRL_STATE) == 0) {
    rf_flags |= WAS_OFF;
    on();
    intern_onoff = 1;
  }

  /* Wait on RSSI_VALID */
  while((REG(RFCORE_XREG_RSSISTAT) & RFCORE_XREG_RSSISTAT_RSSI_VALID) == 0);

  if(REG(RFCORE_XREG_FSMSTAT1) & RFCORE_XREG_FSMSTAT1_CCA) {
    cca = CC2538_RF_CCA_CLEAR;
  } else {
    cca = CC2538_RF_CCA_BUSY;
  }

  /* If we were off, turn back off */
  if((rf_flags & WAS_OFF) == WAS_OFF && intern_onoff) {
    rf_flags &= ~WAS_OFF;
    off();
    intern_onoff = 0;
  }

  return cca;
}

パケット送信中の消費電流は次のようになります。

UDB送信時のcontiki-osの消費電流

注: ストロボ時間は意図的に 10ms に短縮されました。

#define STROBE_TIME                        RTIMER_ARCH_SECOND / 100

これは、ブロードキャスト メッセージの送信ストローブが 3 つしかない理由を説明しています。

ストロボの持続時間は 3ms です。これは、データ レートが ~140kbps (?) であることを意味します。

于 2014-10-15T12:14:05.603 に答える