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

回答

相关问题