• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 16 subscribers
  • Views 209 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2652R: Other wireless technologies forum

Deric Eldredge
Prodigy 60 points
Part Number: CC2652R
Other Parts Discussed in Thread: CC2538

I am using Contiki-NG with a CC2652R in 802.11.15 mode. The issue I am having is it take up to 62ms after the data has been by the radio for the radio driver to release the data to the OS layer. It seems like it is driven by some timer that must expire before the data is sent up through the stack. My application can not tolerate this delay. Please help. I can not seem to find any setting is the RF.h file to control this. 

Thanks 

  • 0
    TI__Mastermind 23730 points

    Deric,

    IEEE 802.11 is WiFi. Contiki-NG does not support WiFi, and neither does the CC2652R. Do you mean IEEE 802.15.4?

    Also, it is impossible for me to know how you are benchmarking the propagation of a received packet being available in the OS layer (what do you even mean by OS layer?). Please elaborate what setup and configuration you are using with Contiki-NG and CC2652R, how your test setup is, and how you benchmark this.

  • 0 in reply to Severin Suveren
    Prodigy 60 points

    Severin ,

     You are correct. I missed typed it is 802.15.4. I can bench mark it because I am using a proprietary protocol in which the upper layers of the device that receives the transmission must produce an ACK within 18ms (I am not using auto ACK at the radio layer). So I start a timer as soon as I send the message out and measure the elapsed time that occurred when the data from the ACK comes in. I also turn the radio off after the 18ms and the data comes in about 62ms after that. The data comes in at that time whether the radio is on or off. I first use this code on the CC2538 and it received that ACK response in about 8ms. I am still using the CC2538 code to send the ACK for both the CC2652R chip and the CC2538 benchmarks.There is something in the 2652 delaying the data because both 2652 and 2538 receive the ACK packet at the same time, but the data from the 2652 does not get pushed for 62ms where as on the 2538 it is almost instantaneous when the data is delivered. 

  • 0
    Prodigy 60 points

    Part Number: CC2652R

       I am using Contiki-NG with a CC2652R in 802.15.4 mode. The issue I am having is it take up to 62ms after the data has been by the radio for the radio driver to release the data to the OS layer. It seems like it is driven by some timer that must expire before the data is sent up through the stack. My application cannot tolerate this delay. Please help. I cannot seem to find any setting is the RF.h file to control this.

       I can benchmark the time delay because I am using a proprietary protocol in which the upper layers of the device that receives the transmission must produce an ACK within 18ms (I am not using auto ACK at the radio layer). So I start a timer as soon as I send the message out and measure the elapsed time that occurred when the data from the ACK comes in. I also turn the radio off after the 18ms and the data comes in about 62ms after that. The data comes in at that time whether the radio is on or off. I first used this code on the CC2538 and it received that ACK response in about 8ms. I am still using the CC2538 code to send the ACK for both the CC2652R chip and the CC2538 benchmarks. There is something in the 2652 delaying the data because both CC2652R and CC2538 receive the ACK packet at the same time, but the data from the CC2652R does not get pushed for 62ms whereas the CC2538 delivers the received data to the application layer almost instantaneously. 

    Thanks

  • 0 in reply to Deric Eldredge
    TI__Mastermind 23730 points

    My first questions is why don't you use the auto ACK feature? I assume the problem arises that you are implementing ACK'ing in software, the delay receiving the packet and realizing you should send an ACK is too big, and hence the transmitting device doesn't receive the ACK.

    The CC2652R has auto-ACK support for a reason, in order to meet the tight time requirements for the turnaround time to send an ACK.