• State Resolved
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 149 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

CC2652R7: Setting up advertising intervals.

Nick Braun
Prodigy 90 points
Part Number: CC2652R7

Tool/software:

Hello
I am developing a multirole-based application and I have the following task:
I have several devices that are located near each other. Under some condition, they (all, or just some) can go on air with broadcast messages (advertising) for some time (T1). At the same time, they themselves must scan the air during the time (T1) and find neighboring devices that are currently broadcasting on the air.

While I was setting this up, I had several questions.
1. The most important, what is the best way to configure the parameters to guarantee 100% of all my devices are on the air: GAP_ADV_PARAM_PRIMARY_INTERVAL_MIN and GAP_ADV_PARAM_PRIMARY_INTERVAL_MAX (the comments say that the second parameter is not actually used), SCAN_INTERVAL and SCAN_WINDOW?


2. When I studied the theory about advertising, it was written that according to the BLE standard, the device broadcasts on three channels (37,38,39) for no more than 10 ms on each. I conducted an experiment with one device that simply broadcasts on the air and used the NRF sniffer and wireshark. I see broadcast packets on different channels, but the time between them is about 850 μs, regardless of the settings of the GAP_ADV_PARAM_PRIMARY_INTERVAL_MIN and GAP_ADV_PARAM_PRIMARY_INTERVAL_MAX values. Why is that? Why does the broadcast duration not increase to 10 ms?


Now I have achieved the optimal configuration option, when GAP_ADV_PARAM_PRIMARY_INTERVAL_MIN = GAP_ADV_PARAM_PRIMARY_INTERVAL_MAX = 32 (32*0.625 = 20ms)
SCAN_WINDOW = 32 (20ms)
SCAN_INTERVAL = 64 (40ms)
Scan type - passive

Scanner Duplicate Filter - disable

I proceed from the following logic: each device at one point in time can either broadcast on the air or scan it. Therefore, I set the scanning interval to 40ms, of which 20ms will be spent on active scanning (scan window), and the other 20ms will be spent on broadcasting on the air. Considering that after each scan a pseudo-random delay of up to 10ms is added, I expect that due to the short time and additional delay I will achieve a situation where some devices are scanning, while others are broadcasting at the same time and therefore will be able to see each other.
In general, this logic works successfully in about 80% of cases, but if you disable the duplicate filter, it works almost 100%. I don't quite understand how the filter affects this?

What strategy is best to follow to ensure that all devices that go on the air can find their neighbors?

  • +1
    TI__Mastermind 38240 points

    Hi,

    An advertising event (if all three channels are enabled) will consist of three individal advertisements being sent back to back. One on each channel. The advertising interval (controlled by suing the GAP_ADV_PARAM_PRIMARY_INTERVAL parameters) determines the time between advertising events. You will need to measure the time between the advertising events and not the individual PDUs as this could cause some confusion.

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 90 points

    hello

    I understand that the GAP_ADV_PARAM_PRIMARY_INTERVAL parameter defines the time between advertizing events. But why do I see broadcasts on different channels with an interval of less than 1 ms? Shouldn't they broadcast for a longer time on one channel? Or are such short broadcast intervals a feature of the BLE stack implementation from TI?

  • 0 in reply to Nick Braun
    TI__Mastermind 38240 points

    Hi,

    My apologies, I misunderstood your question. The time between each advertisement inside of an advertisement event is very small and the transmission time of each advertisement is also very small. This is by design as specified int he Bluetooth LE specification. In section 4.4.2.3 Connectable and Scannable undirected event type of the specification, it is specified that the time between two advertisements (ADV_IND PDUs) must be no more than 10ms. So any time less would be acceptable as well:

    The actual transmission time of each packet would be in the order of microseconds.

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 90 points

    Hello
    According to the TI picture that I posted above and which I use as a reference, in one advertizing event three channels broadcast in turn, each of which is no longer than 10 ms.
    According to your message, it now sounds a little like this:
    During one advertizing event (we configure the time using GAP_ADV_PARAM_PRIMARY_INTERVAL_MIN), the device broadcasts many times in turn on each of the three channels (in my case, the broadcast time on one channel is about 850 µs), and not just three times as in the picture. Am I right?

  • 0 in reply to Nick Braun
    TI__Mastermind 38240 points

    Hi,

    In an advertising event, the device will advertise three times (one on each channel) and then wait until the advertising interval has elapsed (set by GAP_ADV_PARAM_PRIMARY_INTERVAL_MIN) before starting another advertising event. The time between an individual advertisement (on a given channel) and the next advertisement (on another channel) will not exceed 10ms.

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 90 points

    Hi,

    then it confused me even more.
    I configure the advertizing parameters in the code through the GapAdv_params_t structure. This structure has two parameters that are responsible for the advertizing interval: primIntMin and primIntMax.
    The source code says that primIntMax (GAP_ADV_PARAM_PRIMARY_INTERVAL_MAX) is not used, since the primIntMin parameter (GAP_ADV_PARAM_PRIMARY_INTERVAL_MIN) is always used.
    I have both values ​​​​set to 32, that is, 32 * 0.652 ms = 20 ms, this is the duration of one of my advertizing intervals.
    Within one interval (20 ms), the device broadcasts on three channels (37, 38, 39) in turn.
    According to wireshark, I see that the channel broadcasting is repeated every 20 ms, which corresponds to the interval. But within one interval, the broadcast time on each channel is slightly less than 1 ms. It turns out as if during 20 cm (one interval) the device broadcasts on each channel for 850 µs and then simply waits for the end of the interval.
    Is this the correct behavior of the stack? Because I expected that the broadcast duration would increase proportionally to the duration of the advertizing interval (not exceeding the limit of 10 ms)
    I still do not understand how the stack calculates the broadcast time on each channel within one advertizing interval.

  • 0 in reply to Nick Braun
    TI__Mastermind 38240 points

    Hi,

    I believe your understanding is correct with the exception of the proportionality behavior. I do not believe this is a behavior that is described by the Bluetooth LE specification. Can you clarify where you found this requirement? When you say broadcast time, are you referring to the time the TX is active during an individual advertisement? If so, then this I believe is specified by the specification as well.

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 90 points

    Hi

    About proportionality it was only my guess. I based it on the presented information and images. It is not entirely clear to me why broadcasting on one channel (pduInterval) is no more than 10 ms, but the actual duration of active broadcasting is less than 1 ms. What is the point of this? Only energy saving?

    My logic was that we can configure the duration of advertising events (in my case 20 ms), and in this time interval, each channel broadcasts an equal amount of time, but no more than 10 ms (that is, 20/3 = 6.66 ms).

    In fact, it turns out that no matter what interval time I set in my application, the duration of active broadcasting on each channel will be about 850 μs, and the rest of the time there will be silence?

  • 0 in reply to Nick Braun
    TI__Mastermind 38240 points

    Hi,

    Got it. To provide a bit of context, the Bluetooth LE specification was designed with the purpose of being as low power as possible while still maintaining good communication performance. The protocol achieves this low power by maximize the off-time and the time that the radio is not transmitting. That is the reason that you are seeing that the device is mostly not transmitting while advertising. The TX time you found for a single advertisement channel event sounds correct for BLE.

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 90 points

    Hi

    Okay, thank you. Let's consider the matter closed.