• State Resolved
  • Replies 4 replies
  • Subscribers 54 subscribers
  • Views 144 views
  • Users 0 members are here
Support feedback
Options
Options
Related

CC1312R: what are the pros and cons between 15.4 Stack FH Low Latency Broadcast mode and FH mode with broadcast enabled?

Zhiyong Li (FT)
Expert 2910 points
Part Number: CC1312R
Other Parts Discussed in Thread: CC1352P,

Tool/software:

Hi,

I was able to port our code for 15.4 stack in FH mode to support FH low latency broadcast (FH-LLB) mode. My first impression is that the power consumption is similar if polling interval and broadcast interval for FH mode is set at 60s, and broadcast interval for FH-LLB mode is set at 30s. I tried to set the broadcast interval for FH-LLB to higher numbers, such as 60s, seems to stop working all together. I guess it might be capped somewhere between 30s and 60s, maybe (32767ms ?). And the joining and rejoining time seems to similar as well.

The benefit of FH-LLB is that collector can send data to sensor node(s) a lot faster, in 15 seconds at most vs 60s at most. But collector in FH mode has a higher throughput for node specific data, because multiple sensor nodes can poll for data in 60 seconds, while collector in FH-LLB mode can only send at most 4 node specific messages.

Can someone with the knowledge elaborate on other possible pros and cons?

Thanks,

ZL

  • 0
    TI__Intellectual 1450 points

    Hi Zhiyong

    Thanks for the interest in FH Low latency broadcast. I'm not aware of the practical limit of the broadcast interval on this mode. I'll come back to you with an answer tomorrow.

    Best,

    Daniel

  • 0 in reply to Daniel Guarecuco Aguiar
    Expert 2910 points

    Hi Mr. Aguiar,

    I am checking in to see if you have had a chance to gather some information on this topic.

    The issue I had with long broadcast interval seems to have been caused by mismatch of crystal accuracy on collector and sensor boards. The collector and sensor nodes used in my test were built around different MCU (CC1352P vs CC1312R) and have different crystal configurations. As the broadcast interval increases, subtle differences in crystal frequency start to make them miss the BROADCAST_DWELL_TIME window. When I tested with sensor and collector nodes from the same design, I had no issue with long broadcast interval as long as 300s.

    Best,

    ZL

  • +1 in reply to Zhiyong Li (FT)
    TI__Intellectual 1450 points

    Hi Zhiyong,

    Sorry for the delay.

    1. The main advantage of using FH-LLB mode is the current savings on the sensor side from not doing a TX on every polling interval. So you should have seen some improvements. Could you explain what are you broadcasting and how are you setting up the network?

    What is you application and what are your requirements? Maybe we could help on analyzing the right mode you need.

    2. The issue with different crystals is expected. As the sensor can only sync with the collector on a broadcast interval, having this interval too far apart can make you miss the entire dwell window as you are experiencing. You could increase the dwell time, reduce the broadcast interval or make sure you use similar crystals. On our side, we have run up to 300s without issues using similar hardware.

    Best,

    Daniel

  • 0 in reply to Daniel Guarecuco Aguiar
    Expert 2910 points

    Hi Mr. Aguiar,

    Thanks for the explanation and also for confirming the broadcast interval up to 300s has been tested working.

    I captured the current traces of sensor nodes polling for data in FH mode, and waking up and listening for data in FH-LLB mode, and used those numbers to calculate the theoretical power consumption. If we set polling interval at 60s, power consumption from polling  alone amounts to about 10 to 30uA depending on TX power. In FH-LLB mode, if we set broadcast dwell time at 50ms, and broadcast interval to 60s, the power consumption by waking up and listening for data is about 17uA. So FH-LLB could reduce power consumption somewhat if TX power is high as in CC13-90. We can increase the broadcast interval even longer, but then the throughput for node specific data will severely handicapped and we risk loosing data.

    We use simplelink MCUs for equipment and environment monitoring, and requires data sent from collector to a specific sensor node occasionally. I think we will stick with FH mode. So far it has been working well, sometimes some sensor nodes will drop off network but that is manageable.

    Best,

    ZL