• TI Thinks Resolved

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

Prodigy 100 points

Replies: 17

Views: 273

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).

  • Genius 15225 points

    Hello Kelly,

    It looks like what you are doing is correct, have you tried to increase the queue size in mac_cfg.c?

    Regards,

    AB

  • In reply to AB:

    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.

  • In reply to Kelly Stearns:

    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

  • In reply to Kelly Stearns:

    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.

  • Genius 15225 points

    In reply to Kelly Stearns:

    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

  • In reply to 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 ?

  • Genius 15225 points

    In reply to Kelly Stearns:

    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.

  • Genius 15225 points

    In reply to AB:

    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

  • In reply to 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.

  • Genius 15225 points

    In reply to Kelly Stearns:

    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