• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 54 subscribers
  • Views 124 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.

CC1312R: are broadcast messages queued on collector in 15.4 FH mode?

Zhiyong Li (FT)
Expert 2920 points
Part Number: CC1312R
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hi,

When testing broadcast transmissions from collector to sleepy sensor nodes, I noticed that most of the time those broadcasted messages will be received by sleepy sensor nodes 90s seconds later. For background, broadcast interval is set at 300s, and broadcast dwell time is set at 100ms.

This makes wonder if those messages were put into a queue, and then sent out one by one every broadcast interval. If so, is there a way to query the size of the queue so we don't overflow it.

Update: I noticed in FH low latency broadcast mode, collector maintains a tally on how many messages have been broadcasted, and only sends out another one if the tally is down to 0. Should we do the same in FH mode too?

Please advise.

ZL

  • +1
    TI__Guru* 82431 points

    Hi Zhiyong,

    In general, messages are queued in the TX buffer. You can find it in software_stack/ti15_4stack/mac/mac_settings/mac_cfg.c. The variable is called MAC_CFG_TX_DATA_MAX (default 2).

    You can use the same event that you refer to in collector.c to keep track of how many broadcasts are sent.

    Cheers,

    Marie H

  • 0 in reply to Marie H
    Expert 2920 points

    Hi Marie,

    Thanks for your response. Could you help explain the 90s delay? Even I made sure there is no prior pending broadcast message via the mechanism used in FH-LLB mode, all broadcast messages sent out so far reached sleepy sensor nodes exactly 90s later. I can accept the delay as long as it is always like this.

    Best,

    ZL

  • 0 in reply to Zhiyong Li (FT)
    TI__Guru* 82431 points

    Hi Zhiyong,

    The broadcast interval you set in sysconfig is divided by two by the TI 15.4-Stack, so I would expect the sensor to get the message after 150 s (300 / 2), but there should also be a dependency on where in the interval the packet is scheduled.

    Can you use energy trace to check how often broadcasts are being sent? (If it's every 90 s or every 150 s)

    Cheers,

    Marie H

  • 0 in reply to Marie H
    Expert 2920 points

    Hi Marie,

    Thanks for your reply. I later tested the timing of broadcasted messages with different broadcast interval. When the interval is set at 60s, or 180s, broadcast messages seem to arrive at sleepy sensor nodes without delay during my brief test with 4 sleepy sensor nodes. When I tested again with 300s interval, the 90s delay still exists.

    You mentioned in your earlier post that both broadcast and unicast messages share the same TX queue. I guess that might the cause of this delay. If one or more unicast messages are put into queue and are pending sleepy sensor nodes to poll for it. Broadcast messages probably won't be actually sent out until prior unicast messages are sent.

    I was planning to use broadcast to send out RTC time sync packets, but I guess I may have to give up the idea.

    Best,

    ZL

  • +1 in reply to Zhiyong Li (FT)
    TI__Guru* 82431 points

    Hi Zhiyong,

    That sounds very plausible.

    The sensors do already use the broadcast messages to sync and adjust their timing to collector.

    Cheers,

    Marie H