• State Not Answered
  • Replies 1 reply
  • Subscribers 24 subscribers
  • Views 76 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 290003
Options

Advertising interval value keep fluctuating

user110654


I am using nRF52833 DK and I am running Light switch server in one DK and Client in another DK
Advertising interval was way too high(around 9Second)
so decided to change it.

Defined a interval of 50ms and under mesh_adv.c file, have defined this MACRO and changed duration and interval parameters.

#define CUSTOM_ADV_INTERVAL MSEC_TO_UNITS(50, UNIT_0_625_MS)

.
.
.
.
.

m_adv_params.duration = 0;
m_adv_params.interval = CUSTOM_ADV_INTERVAL;

Now the Advertising interval have been reduced, but it keeps on fluctuating

.
I am using nRF connect App to check the ADV interval timer, for some time it scans at 20ms and for some time scans at 100ms

I expect that to be around 50ms(+ or - 50ms) constantly.

Is this behavior expected ?

Is this fluctuating is normal ?

Any feedback would be helpful

Thanks in Advance.

Sarjoon.

Parents
  • 0

    Hi,

    Since you refer to the file mesh_adv.c, I assume you are working with the nRF5 SDK for Mesh, and I assume the latest release which is v5.0.0.

    Advertisements are used for several purposes. One of them is for sending Bluetooth mesh packets, which will happen as needed and within a restriction of maximum 100 messages sent within a sliding 10 second window. Therefore, if you push throughput (sending) from a node, you could experience a burst of packets, then a pause since you have sent 100 messages and you must wait until there has been 10 seconds since the first packet and then you will can get a burst again. Could the issue you describe (9 second interval) be related to that? I.e. how many messages are you sending from your node, and with what interval?

    Our Bluetooth stack (the SoftDevice) schedules all activity, including advertisements, scanning, connections, etc. according to certain rules, see SoftDevice timing-activities and priorities. If too much activity is scheduled, then some of the desired timings for those activities will collide. When collisions occur, one activity is schedule while any other activities are not. By decreasing the advertising interval for one advertising activity, the chances are it collides with other activity. The Bluetooth mesh stack and the Bluetooth mesh examples are tuned to get good overall performance, and changing interval values may end up giving more collisions, which could make performance worse.

    Further, the particular advertising setting that you change may be related to a different advertising system than the one you are looking at.

    What kind of advertising are you looking at, is it the ADV bearer mesh packets, is it advertising as GATT proxy node, or is it concurrent BLE activity?

    How do you measure the long interval, do you have a sniffer trace?

    Regards,
    Terje

Reply
  • 0

    Hi,

    Since you refer to the file mesh_adv.c, I assume you are working with the nRF5 SDK for Mesh, and I assume the latest release which is v5.0.0.

    Advertisements are used for several purposes. One of them is for sending Bluetooth mesh packets, which will happen as needed and within a restriction of maximum 100 messages sent within a sliding 10 second window. Therefore, if you push throughput (sending) from a node, you could experience a burst of packets, then a pause since you have sent 100 messages and you must wait until there has been 10 seconds since the first packet and then you will can get a burst again. Could the issue you describe (9 second interval) be related to that? I.e. how many messages are you sending from your node, and with what interval?

    Our Bluetooth stack (the SoftDevice) schedules all activity, including advertisements, scanning, connections, etc. according to certain rules, see SoftDevice timing-activities and priorities. If too much activity is scheduled, then some of the desired timings for those activities will collide. When collisions occur, one activity is schedule while any other activities are not. By decreasing the advertising interval for one advertising activity, the chances are it collides with other activity. The Bluetooth mesh stack and the Bluetooth mesh examples are tuned to get good overall performance, and changing interval values may end up giving more collisions, which could make performance worse.

    Further, the particular advertising setting that you change may be related to a different advertising system than the one you are looking at.

    What kind of advertising are you looking at, is it the ADV bearer mesh packets, is it advertising as GATT proxy node, or is it concurrent BLE activity?

    How do you measure the long interval, do you have a sniffer trace?

    Regards,
    Terje

Children
No Data
Related
Terms of service