Precision of an advertising interval and clock calibration

RE: Precision of an advertising interval and clock calibration

Hieu — Wed, 11 Dec 2024 16:37:34 GMT

Hi Paskin,

In requirement language, "should" means not mandatory, but recommended.
In the Bluetooth Core Specification, this is described in Vol 1, Part E, Section 1, Language Convention.

So, you can use the same value. The reason for not doing so is explained in the text you quoted.

However, it doesn't seem like permitting a range is of interest to you any way, considering that you want exact timing.

For exact timing, you can look into the Periodic Advertising feature. It does require the scanner to also support Periodic Advertising.
You can read more about it here: What You Need to Know About Periodic Advertising Sync Transfer | Bluetooth® Technology Website.

RE: Precision of an advertising interval and clock calibration

Paskin — Wed, 11 Dec 2024 16:19:56 GMT

Hello Hieu,

Thanks for your response.

By "BT Spec" I referred to the comment in NRF Connect header v.2.5.1/zephyr/include/zephyr/bluetooth/bluetooth.h, which in lines 739-740, as well as 748-749 reads:

Maximum Advertising Interval should not be the same value (as stated in Bluetooth Core Spec 5.2, section 7.8.5)

Referred section of the Core Spec - contains the following sentence:

The Advertising_Interval_Min and Advertising_Interval_Max should not be the same value to enable the Controller to determine the best advertising interval given other activities.

Considering your comment about random delays - Is there a way to send advertisements with the constant interval? I am trying to implement a sensor, which - when triggered - transmits readings as frequently as possible and with high precision of a time line. Unfortunately, it cannot know who is listening and there could be multiple listeners as well (i.e. directed advertising is not possible).

Please advise.

RE: Precision of an advertising interval and clock calibration

Hieu — Fri, 06 Dec 2024 12:45:23 GMT

Hi Paskin,

It's great that you have referred to the BT specification to find your answer. There seems to be some misunderstanding, and I would be happy to help clear them up.

[quote user=""]I've set the interval_max to 100ms/0.625 = 160, and interval_min to 159, as by the BT spec they cannot be equal (setting to 160 doesn't change the picture though).[/quote]

The Bluetooth spec does not require Connection Interval Min to be smaller than Connection Interval Max at all. All specifications are along the line of "min shall not be greater than max."

Refer to Vol 4, Part E, 7.8.5, LE Set Advertising Parameters.

[quote user=""]In the test, conducted against Linux machine - I see that the distance between the received packets is ~103-105 ms (average over ~1000 packets). I can tweak it to become 100 by reducing the interval value by 5-7 0.625th - but the correction has to be found individually for each board instance. [/quote]

There is a random 0-10ms delay added to every advertising event. That is why you see the average interval between advertising packets being about 105ms.

Refer to Vol 6, Part B, 4.4.2.2.1 Advertising interval.

Hieu