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

I haven't tried anything with mac_cfg.c .... how would that be related ? 

It's only sending the default (very small) broadcast messages, and for it to work, it clearly must be able to deliver a single small packet within a given broadcast window.

I'll try increasing to see if it has any effect - if there is a certain value I should use, please reply back, otherwise I will just double it a few times and check result.

Thanks.

I tried doubling and tripling the following values, with no change in behavior - broadcast transmits still fail.

Next idea ?

/* maximum number of data frames in transmit queue */
#ifndef MAC_CFG_TX_DATA_MAX
#define MAC_CFG_TX_DATA_MAX 2
#endif

/* maximum number of frames of all types in transmit queue */
#ifndef MAC_CFG_TX_MAX
#define MAC_CFG_TX_MAX 5
#endif

/* maximum number of frames in receive queue */
#ifndef MAC_CFG_RX_MAX
#define MAC_CFG_RX_MAX 2
#endif

As I mentioned previously, my sample code to reproduce this problem is directly from the 03.20.00.68 Simple Collector/Sensor sample application running on a pair of LaunchPad CC1352P1 boards.

Our R&D had been on hold for 3 weeks already with no progress on this issue, so we cannot afford more back-and-forth round-trip delays while guessing at possible causes, so please test the following changes (on Controller and Sensor) on your own boards to reproduce and root cause :

#define CONFIG_FH_ENABLE = true

#define CONFIG_DWELL_TIME = 25

#define FH_BROADCAST_INTERVAL 50

#define FH_BROADCAST_DWELL_TIME 25

Thanks.

Hey Kelly,

We are now running test on our end, I will let you know as soon as I get a better idea of what is going on and a solution to this problem.

We apologize for any inconvenience this may be causing.

AB

Any updates ?

Just to clarify, you we are able to reproduce the problem we are seeing and are now working on a resolution, correct ?

Hello Kelly,

Yes, I was able to r3eproduce and I am in the process of understanding why and testing different solutions.

Thank you for your patience, know that we are working on this.

Hello Kelly,

After further testing and attempting to fix the 'issue' I was not able to go under 200ms.

Can you explain in more detail why would you want to have FH + broadcast msgs so fast?

I can help you in getting a network topology that would be better suited for your application.

Looking forward to hearing from you,

AB

No offense, but I've known for weeks that it wouldn't work under 200ms (even 500ms gets unreliable) - the question is why ?

What is the root cause preventing use of timer values which are stated as supported in the MAC API ?

That's the information that I am expecting your team to provide.

Our application requires reliable, real-time updates of scoring timers every 1/10th second. Since the updates are real-time, they cannot be retransmitted or they will be inaccurate, so we need to send at least 2 updates per 1/10th second, on 2 different frequencies for frequency diversity, to ensure reliable operation. This is how the current 900mhz system (which we are replacing due to EOL parts) achieves reliability - it actually sends 25ms (4 times per 1/10th of second) with each on a different hop channel. It requires a star topology, dynamically-established with a root node and up to 24 leaf nodes.

We are certainly interested to hear about alternative solutions, but time is short - we've wasted nearly a month trying to get an answer to this relatively simple question (and still don't have an answer).

We must have a solution proven out by the end of October or we will have to go with a Nordic 2.4Ghz solution. We would prefer a 900mhz solution for range and penetration, but the Nordic at least works as advertised.

Hello Kelly,

I am sorry for the delay on our part, I want you to know that it has been been one of my priorities to work on this and I have not stopped since I have taken this action.

We have found a mismatch between our documentation min and max accepted values and what is actually implemented in our stack, luckily this is fixable from application side.

Go to mac_cfg.c on line 486 you will see :

{offsetof(FHPIB_DB_t, macBcInterval), sizeof(uint32_t), 250, 16777215},

modify 250 with 50, this should allow you to configure any value all the way to 50ms.

I am still attempting some tests, but  I wanted to get back to you with some information.

Sorry for the inconvenience,

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 ?

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 ??

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.

Regards,

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.

QUESTIONS:

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.

Kelly,

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.