• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 55 subscribers
  • Views 1080 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Contiki on CC2538: ContikiMAC and phase-lock optimization

Thomas Hassler
Prodigy 140 points

Other Parts Discussed in Thread: CC2538, CC2420

Hello,


I'm using Contiki on a CC2538DK. To reduce power consumption I want to use the radio duty cycling protocol ContikiMAC and to further be able to reduce the number of sent strobes I want to use the ContikiMAC phase-lock optimization:


By default the phase-lock optimization is disabled on the CC2538dk platform while that isn't the case with the other platforms like Tmote Sky.


The problems occuring when enabling the ContikiMAC phase-lock optimization on CC2538 is that a lot of messages are not received.

Is it possible to make the ContikiMAC phase-lock optimization work in a proper way on CC2538? Actually, I couldn't figure out what the problem is yet.

  • 0
    TI__Genius 12480 points
    I am not aware of anyone that has tested this feature on the cc2538, maybe try to post the same question on the Contiki lists?

    -Jonas
  • 0 in reply to Firefighter
    Prodigy 140 points
    I did ;-) Thank you anyway!
  • 0 in reply to Thomas Hassler
    Expert 1525 points
    Hi,

    while not being fully up-to-speed with exactly how well the Contiki phase-lock optimization works today, I can speak generally about ContikiMAC.

    ContikiMAC started out as a highly-optimized radio duty cycling protocol in Contiki OS written for the cc2420 radio. Like X-MAC and other low-power listening protocols (as opposed to low-power probing protocols), ContikiMAC sleeps most of the time but with a fixed periodicity turns on the radio and listens. The sender transmits the data packet repeatedly. For a unicast, the sender listens for a short while after the send, and the receiver sends an ACK. In a broadcast, the sender just keeps sending and the receiver goes back to sleep.

    Compared with X-MAC, ContikiMAC optimizes the wake-up into a series of CCA-checks. This only wakes up the radio enough to get a valid RSSI measurement, which is very short.

    Phase-lock optimization is when a sender of a unicast receives an ACK, it also implicitly knows when the other device wakes up, ie the wake-up schedule.

    As you can imagine, ContikiMAC manages to be power efficient due to many optimizations which are very hard to get right, and quite hard to port to new radios as they have different characteristics, even within the TI ccYYYY-lines. There are just so many things that may go wrong or differ. For example, drift due to differences in device crystal oscillator temperature stability may drift one device over time compared to another. A device that for some reason (perhaps an application that takes an RSSI sample) turns on the radio receives a packet early in the wake-up cycle may lead the sender to believe it has a differing schedule than it actually has. And so on and so on. It's just really, really hard to get working robust and well over time in a wide range of traffic situations.

    There are a lot of things happening in Contiki for the cc2538 right now, there may have been updates so that it is worth revisiting and trying it again.

    At our place (Thingsquare) we run a modified version of CSL and always test new radios and platforms extensively to ensure our optimizations work well. After a couple you tend to have a battery of tests to run :)