Contiki UDP數據包傳輸持續時間與CC2538

有人可以解釋我Contiki-OS內傳輸UDP數據包時發生了什麼？Contiki UDP數據包傳輸持續時間與CC2538

這裏是我的設備的細節的電流消耗與CC2538芯片運行：

CC2538 Current consumption

我的問題是：爲什麼需要這麼長的傳輸知道一個UDP廣播數據包（約250毫秒）理論上在250kbps時，應該在大約2ms內傳輸408比特長度的分組？我會理解，如果最後的傳輸說可以說十毫秒，但這裏的差異是巨大的。

我使用contiki/examples/ipv6/simple-udp-rpl/broadcast-example.c

的例子有沒有人有一個想法？

來源

2014-10-03 Darko P.

我發現這個問題：傳輸數據包後收音機沒有正確關閉。

在文件cpu/cc2538/dev/cc2538-rf.c中功能transmit()的末尾，無線電僅在之前關閉時關閉。

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; 
}

一個分組傳輸期間的電流消耗現在看起來像：

Current consumption of contiki-os when UDB transmission

注：選通時間被有意降低到10ms與：

#define STROBE_TIME      RTIMER_ARCH_SECOND/100

這解釋爲什麼廣播消息只有三個傳輸頻閃。

頻閃持續時間爲3ms。這意味着數據速率是〜140kbps（？）。

來源

2014-10-15 12:14:05

默認情況下，Contiki使用ContikiMAC無線工作循環（RDC）協議。該協議必須處理兩個衝突的要求：允許接收器節點幾乎在沒有數據包要接收的時候進入睡眠狀態，但同時允許儘可能可靠地傳送數據。 ContikiMAC採用的解決方案是將負擔放在發射器上。假設接收機每秒檢查8次無線電信道（cc2538dk平臺上的默認配置），則發射機必須至少發射125ms的持續時間，以確保接收機已喚醒並看到數據包。實際上，這意味着一個數據包在一行中被多次重新傳輸。有關更詳細的說明，請參閱ContikiMAC paper和Contiki documentation。

這就是說，你不會總是看到最大持續時間的傳輸。如果是單播，則接收器通常在成功接收後發送ACK。發送器檢查此ACK，並在收到時停止發送。這樣，預期的平均傳輸次數減少了兩次。然後還有Phase Optimization - 它允許發送器將傳輸的開始與接收器的預期喚醒時間同步。但對於廣播而言，不會產生ACK並且階段優化不會起作用。

意外長時間傳輸的另一個可能原因是CCA檢查失敗。在發送數據包之前，無線電堆棧首先檢查媒體是否空閒;如果不是，它會備份一段時間並重試。

來源

2014-10-03 18:30:47 kfx

謝謝您的完整描述。我已經懷疑8Hz的CCA檢查，因爲250ms的持續時間是雙週期。它似乎是收音機沒有正常關閉，它必須等待下一次無線電檢查，然後再試。 – 2014-10-07 07:12:50

Contiki UDP數據包傳輸持續時間與CC2538

回答

相關問題