Contiki CC2538을 사용한 UDP 패킷 전송 지속 시간

Question

누군가 Contiki-OS에서 UDP 패킷을 전송할 때 무슨 일이 일어나는지 설명 할 수 있습니까? 여기

은 CC2538 칩을 실행 세부 사항에 내 장치의 소비 전류 :

내 질문은 : 것을 알고 UDP 브로드 캐스트 패킷 (약 250 밀리 초)을 전송하는 데 너무 오래 걸리는 이유 이론적으로 250kbps에서 408 비트 길이의 패킷은 대략 2ms 이내에 전송되어야합니까? 나는 전송이 최후에 10 밀리 초를 말하게하는 것을 이해할 것이다. 그러나 여기의 차이는 거대하다.

나는 누군가가 생각이 있습니까

contiki/examples/ipv6/simple-udp-rpl/broadcast-example.c의 예를 사용할 수 있습니까?

Answer 1

문제를 발견했습니다 : 라디오가 패킷 전송 후 올바르게 꺼지지 않습니다.

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

패킷 전송시 소비 전류는 지금과 같은

#define STROBE_TIME      RTIMER_ARCH_SECOND/100 

이 : 스트로브 시간으로 10ms의에 의도적으로 감소 왜 방송 메시지에 대해 전송 스트로브가 세 번 있는지 설명하십시오.

스트로브의 지속 시간은 3ms입니다. 즉 데이터 속도는 ~ 140kbps (?)입니다.

Answer 2

기본적으로 Contiki는 ContikiMAC RDC (radio duty cycling) 프로토콜을 사용합니다. 이 프로토콜은 두 가지 상충되는 요구 사항을 처리해야합니다. 수신 할 패킷이 없을 때 수신기 노드가 거의 항상 잠자기 상태가되도록 허용하지만 가능한 한 안정적으로 데이터를 전달할 수는 있어야합니다. ContikiMAC에 채택 된 솔루션은 송신기에 부담을주는 것입니다. 수신자가 초당 8 번 (cc2538dk 플랫폼의 기본 구성) 라디오 채널을 확인하면 송신기는 수신기가 깨어나서 패킷을 보았는지 확인하기 위해 최소 125ms의 지속 시간을 전송해야합니다. 실제로 이것은 패킷이 연속으로 여러 번 재전송된다는 것을 의미합니다. 자세한 내용은 ContikiMAC paper 및 Contiki documentation을 참조하십시오.

그렇다면 최대 전송 시간을 가진 전송을 항상 보지 못할 것입니다. 유니 캐스트 인 경우 수신자는 정상적으로 수신 성공 후 ACK를 보냅니다. 송신기는이 ACK를 확인하고 수신 된 경우 송신을 중지합니다. 이 방법을 사용하면 필요한 평균 전송 횟수가 두 번 줄어 듭니다. 그리고 나서 Phase Optimization도 있습니다. 이것은 송신자가 송신 시작을 수신자의 예상 웨이크 업 시간과 동기화 할 수있게합니다. 그러나 브로드 캐스트의 경우 ACK가 생성되지 않고 위상 최적화가 작동하지 않습니다.

예기치 않게 오래 전송할 수있는 또 다른 이유는 실패한 CCA 검사입니다. 패킷을 전송하기 전에, 무선 스택은 먼저 매체가 빈 상태인지 확인합니다. 그렇지 않다면 잠시 후 다시 시도하고 다시 시도하십시오.