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 ?
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Kelly Stearns:
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.
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 ??
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.
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.
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.
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.