Embedded 使用CC2538的Contiki UDP数据包传输持续时间

有人能解释一下Contiki OS在传输UDP数据包时发生了什么吗

以下是使用CC2538芯片运行的我的设备的详细电流消耗：

我的问题是：如果知道理论上在250kbps时408位长度的数据包应该在大约2ms内传输，为什么传输UDP广播数据包（大约250ms）需要如此长的时间？我能理解传输是否持续10毫秒，但这里的差异很大

我在

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

---

有人有主意吗

默认情况下，Contiki使用ContikiMAC无线电工作循环（RDC）协议。该协议必须处理两个相互冲突的要求：允许接收器节点在没有数据包接收时几乎一直处于睡眠状态，但同时允许尽可能可靠地传送数据。ContikiMAC采用的解决方案是将负载放在变送器上。假设接收机每秒检查无线信道8次（cc2538dk平台上的默认配置），发射机必须至少发射125毫秒，以确保接收机已唤醒并看到数据包。实际上，这意味着一个数据包在一行中被重传多次。有关详细说明，请参见和

也就是说，您不会总是看到具有最大持续时间的传输。如果是单播，则接收器通常在成功接收后发送ACK。发射机检查此ACK，并在收到时停止发送。这样，所需的预期平均传输次数减少了两倍。此外，它还允许发送方将传输的开始时间与接收方的预期唤醒时间同步。但是对于广播，不会生成ACK，并且相位优化也不会起作用

---

意外长传输的另一个可能原因是CCA检查失败。在发送分组之前，无线电堆栈首先检查媒体是否空闲；如果没有，它将备份一段时间，然后重试。

我发现了问题：发送数据包后，收音机没有正确关闭

在文件

cpu/cc2538/dev/cc2538 rf.c

中的函数

transmit（）

结束时，收音机仅在先前关闭时关闭

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

但实际上，在这种情况下，节目永远不会播出，而且在发送数据包后，收音机也不会立即关闭

出现此问题的原因是函数

channel\u clear（）

（在

transmit（）

函数开头调用）首先清除此标志。因此，函数

transmit（）

在执行之前不再知道收音机已关闭，因此收音机保持打开状态

为了解决这个问题，我在

频道\u clear（）

中加入了一个局部变量，该变量只有在函数本身内部打开时才关闭收音机并清除标志

static int
通道_清除（无效）
{
int cca；
/*修正：局部变量*/
uint8实习生离职；
intern_onoff=0；
PRINTF（“RF:CCA\n”）；
/*如果我们关了，先打开*/
if（（REG（RFCORE\u XREG\u FSMSTAT0）&RFCORE\u XREG\u FSMSTAT0\u FSM\u FFCTRL\u状态）=0）{
rf|U标志|=关闭；
on（）；
实习医生=1；
}
/*等待RSSI_有效*/
而（（REG（RFCORE\u XREG\u RSSISTAT）&RFCORE\u XREG\u RSSISTAT\u RSSI\u VALID）=0）；
if（REG（RFCORE\U XREG\U FSMSTAT1）和RFCORE\U XREG\U FSMSTAT1\U CCA）{
cca=CC2538_RF_cca_清除；
}否则{
cca=CC2538_RF_cca_忙碌；
}
/*如果我们关掉了，就把它关掉*/
if（（rf_标志和WAS_关闭）=WAS_关闭和实习生_开启关闭）{
rf_标志&=~已关闭；
off（）；
intern_onoff=0；
}
返回cca；
}

数据包传输期间的电流消耗现在看起来如下：

注意：选通时间故意减少到10ms，包括：

#define STROBE_TIME                        RTIMER_ARCH_SECOND / 100

这就解释了为什么广播信息只有三次频闪传输

---

选通的持续时间为3ms。这意味着数据速率约为140kbps（？）

谢谢你的完整描述。我已经怀疑CCA检查为8Hz，因为250ms的持续时间是双周期。收音机似乎没有正确关闭，必须等待下一次收音机检查后再重试。