• TI Thinks Resolved

CCS/CC1352P: Broadcast interval not working below roughly 500ms

Prodigy 100 points

Replies: 17

Views: 269

Part Number: CC1352P

Tool/software: Code Composer Studio

I'm running the Collector/Sensor sample app on the Launchpad boards.

I'm running with FH enabled and tested with various CONFIG_DWELL_TIME and FH_BROADCAST_DWELL_TIME and everything seems to work fine, all the way down to 25ms dwell intervals - which is what we're wanting for our application.

However, we also need to be able to broadcast periodically at ~50ms intervals and whenever I decrease the FH_BROADCAST_INTERVAL to less than ~500ms, the broadcasts either stopping working or get very infrequent or unreliable. I tracked the root cause of the failure to the sendBroadcastMsg() function in collector.c which is failing to send and returning error code ApiMac_status_transactionOverflow (0xF1).

What does this error mean and why is it unable to broadcast at shorter intervals ?

The MAC API docs state that the FH_BROADCAST_INTERVAL can be configured for any value of 0 or more (where 0 disables it), so I would expect any value to work, especially if it is at least larger than the configured dwell intervals (which it is).

  • In reply to AB:

    Thanks, we will be testing this in the morning and let you know what we find.

    Has your testing shown that it fixes the problem ?

  • Genius 15225 points

    In reply to Kelly Stearns:

    Hello Kelly,

    I wanted to reach out to let you know that I have not successfully gotten a stable connection at set intervals. I am attempting to understand where exactly are these delays happening (radio, stack, FH, etc..) to see if there is any knob we can turn to make it better.



  • In reply to AB:

    Thanks, AB.

    We are seeing similar results - it now allows us to configure the smaller broadcast interval and dwell times and it appears to be using them, but the error rates on broadcasts are very high.

    At 250ms broadcast interval (and 25ms dwell time), we see about 2% RX fails, but it steadily increases to 20% RX fails as the broadcast interval is reduced down to 50ms.

    So it seems like there are definitely issues in the underlying stack that's preventing it from working reliably .... and likely why the other API limit was put into place.

    We are continuing testing too, with various combinations of broadcast interval and unicast and broadcast dwell times to see if we can find any correlations.

    QUESTION: Are there any inherent dependency between those 3 params that should guide how we select them ? I known the broadcast interval must be larger than the broadcast dwell (which is obvious), but from a FHSS scheduler perspective, should the broadcast interval always be a multiple of the broadcast/unicast dwell times ?  or slightly less than or greater than a multiple of ??

  • Genius 15225 points

    In reply to Kelly Stearns:

    Hello Kelly,

    Sorry for the late reply. It has been hard for me to finish the debug, test, and tuning of this scenario. Our office got affected by the storm/tornado and I do not have access to the equipment. 

    I believe you can have the dwell time higher than the interval. The dwell time is for the sensors to listen to the channel while the interval is for the collector to knw when to send it. you should play with the unicast dwell time also, as the FHSS scheduler will use this number to know how long to be in a channel for. This is located under advance_config inside the application folder.

    I tend to use multiples of 5 for my numbers, but the ticks inside the MAC are on 10us basis, so you can go to single units ms and still get good results.



  • In reply to AB:

    Ok, thanks for the reply.

    Good to know on the dwell/interval settings.

    At this point our testing is at a stand-still ... we can't get reasonably reliable packet delivery at anything near our desired intervals/dwells and we don't have visibility to the underlying MAC layer to perform additional debugging.


    Do you see similar TX/RX failure rates during your testing ?  Any idea what's causing it ?

    Is someone going to still be actively working this, or should we assume this won't meet our requirements and move on ? ... our end of October deadline is rapidly approaching.

  • Genius 15225 points

    In reply to Kelly Stearns:


    Yes, I am seeing similar number as you are. I believe the cause might be internal scheduling of the channel hoping and broadcst vs unicast hopping.

    have you tried in non beacon mode to see if you ca get broadcast at those intevals (I know you want to channel hop, but if this works on non beacon then I think the cause might be the scheduler of FH)

    To send a broadcast I would create a timer for the collector (a reporting or broadcast timer) that sends a datareq to a dstAddr of 0x0000 with the no ACK required setting turned on. This should allow every sensor to receive it

    I am actively working on this, with my limited resources.

  • In reply to AB:

    Thanks for the update.

    Keep us posted on progress - if you find something interesting to test, we'll switch back over to the CC1352 testing.

    However, we've had to move on to testing alternative chips/modules, so won't be able to test further unless we see some sort of significant breakthrough that gives us confidence that this might actually work in production.