• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 1282 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.

LAUNCHXL-CC26X2R1: While Advertising, TI BLE Stack adds up a random delay to the advertisement interval

Shiv Pratap Singh
Intellectual 560 points
Part Number: LAUNCHXL-CC26X2R1

Hi,

I have LAUNCHXL-CC26X2R1 boards with CCS v9.1.0 and I am using the simplelink_cc13x2_26x2_sdk_3_10_01_11 SDK for project.

I am working on the Simple Peripheral application and have modified the project so it can supports the 5 Legacy Advertising data set and 1 Extended Advertising data set. For Advertisement, I have to change the advertisement set after each advertisement interval. Because of which I am using different timer of advertisement interval and using GapAdv_enable() and GapAdv_disable() to switch between the advertising data set. So when receive GAP_EVT_ADV_END we disable the advertisement and switch to next advertising set. And whenever timer expires we use GapAdv_enable() to send next advertisement data set.
But when I send GapAdv_enable() to BLE Stack to start advertisement, I receive GAP_EVT_ADV_START_AFTER_ENABLE event after random delay each time. Because of which at central side I receives advertisement data packet at random advertisement interval not at the expected advertisement interval.
I tried to observe how much delay did TI BLE Stack is adding before sending out the first advertisement data packet by calculating the system tick (i.e. in our project 1 tick = 10 micro second) between GapAdv_enable() and GAP_EVT_ADV_START_AFTER_ENABLE. Following are my observation:


From multiple debug session I had observe, BLE stack adds 0ms to around 16ms for each advertising data set before sending first advertisement data packet for advertising. And same is observe at the Central side while receiving the advertisement data set.

Can you please explain this behavior of the TI BLE Stack? Why its adding a delay rather than just directly sending out the advertising data set for advertisement?

Regards,
Shiv

  • 0
    TI__Mastermind 42250 points

    Hello Shiv!

    I will look into this and get back to you as soon as possible!

    Regards,

    Jan

  • 0
    TI__Mastermind 42250 points

    Hello Shiv!

    When sending out advertisements, the Bluetooth specification (see BLUETOOTH CORE SPECIFICATION Version 5.1 | Vol 6, Part B, §4.4.2.2.1) states that the time between advertising events is equal to the advInterval + advDelay. You may change the value of advInterval, but advDelay is a pseudo-random value that is generated by the link layer and cannot be modified. The advDelay can add an additional delay between 0ms to 10ms between advertising events on top of the advInterval delay. This may contribute a portion of the delay you are observing.

    Another possible source of delay may be due to the inherent delay between the GapAdv_enable() function being called and the hardware beginning to advertise. I suggest looking over the Scanning and Advertising SimpleLink Academy lab. The lab discusses changing parameters advertising parameters during runtime which you might find useful. It also discusses the advDelay. The lab also covers how to modify the delay between advertisements. I believe the delay you are experiencing is normal and within spec.

    Regards,

    Jan

  • 0 in reply to Jan
    Intellectual 560 points

    Hello Jan,

    I still have few queries about it. 

    Jan Iglesias Morales said:

    When sending out advertisements, the Bluetooth specification (see BLUETOOTH CORE SPECIFICATION Version 5.1 | Vol 6, Part B, §4.4.2.2.1) states that the time between advertising events is equal to the advInterval + advDelay. You may change the value of advInterval, but advDelay is a pseudo-random value that is generated by the link layer and cannot be modified. The advDelay can add an additional delay between 0ms to 10ms between advertising events on top of the advInterval delay. This may contribute a portion of the delay you are observing.

    As we are using our own timer for advertisement interval. So, the advDelay you are talking about it, Is it added between GapAdv_enable() and GAP_EVT_ADV_START_AFTER_ENABLE event receive. Or Is it added when we started receiving GAP_EVT_ADV_START event  when we start advertisement.

    Jan Iglesias Morales said:
    Another possible source of delay may be due to the inherent delay between the GapAdv_enable() function being called and the hardware beginning to advertise

    Because I have set advertisement interval to 319ms. And when timeout occurs, we called GapAdv_enable() to start advertising the new advertisement data set. And I always receive the advertisement data packet with advertising interval between 319ms to 335ms at central side. So this delay is only because of the inherent delay you are talking about. Or Is it added with advDelay you mention above?

    Regards,
    Shiv

  • 0 in reply to Shiv Pratap Singh
    TI__Mastermind 42250 points

    Hello Shiv!

    The advDelay is included in the time between the start of advertising events (see BLUETOOTH CORE SPECIFICATION Version 5.1 | Vol 6, Part B, §4.4.2.2.1 Fig 4.3). The delay would have already occurred by the time you receive the GAP_EVT_ADV_START. When GapAdv_enable() is called, you may see an additional delay occur due to the inherent delay I mentioned. This inherent delay which would have occurred by the time you receive the GAP_EVT_ADV_START_AFTER_ENABLE event. The delay seen on the central will most likely be a combination of both. If possible, I would suggest modifying the central's code to be able to handle this variation in delay.

    Regards,

    Jan