nRF52 DK - 20ms non connectable advertising interval

[Maximilian Wiens]

Hello, im experimenting around with the nRF52 DK (and nRF51 DK also)

Now I have following setup on nRF52 DK:

SoftDevice: s132 nRF52 v2.0.1

Applicatoin: Example Project from nRF SDK 11.0 (ble_app_beacon)

By the default the interval for advertising is set as following:

#define NON_CONNECTABLE_ADV_INTERVAL MSEC_TO_UNITS(100, UNIT_0_625_MS)

which is equal to 100ms or 160 Ticks.

Accoding to my question here Frequent scanning of multiple BLE beacons, it should be possible to set up the adv. interval to smaller as 100ms (down to 20ms). But when I set

    #define NON_CONNECTABLE_ADV_INTERVAL MSEC_TO_UNITS(20, UNIT_0_625_MS)

or directly as number of Ticks ( (20*1000)/625 = 32)

    #define NON_CONNECTABLE_ADV_INTERVAL 32

or even larger number

    #define NON_CONNECTABLE_ADV_INTERVAL MSEC_TO_UNITS(90, UNIT_0_625_MS)

compile and flash the DK, it does not work. Im using the nRF smarphone app and other BLE scaner apps to check if beacon is available (Android). But the Beacon is displayed only if interval value is >=100ms.

So it seems the chip can not handle that small advertising intevall or the setup is wrong.

Is there a way to force the advertising intervall of less than 100ms in nRF52?

Is it possible with nRF51?

Thanks in advance

[RK]

From the bluetooth spec (Vol 6, Part B, section 4.4.2.2 )

The advInterval shall be an integer multiple of 0.625 ms in the range of 20 ms to 10.24 s. If the advertising event type is either a scannable undirected event type or a non-connectable undirected event type, the advInterval shall not be less than 100 ms

so "it does not work" because the stack will return you an error message when you try to set a non-connectable advertising interval of less than 100ms and the code will jump right to the error handler. The softdevice doesn't allow you to set parameters which are outside the bluetooth spec.

[RK]

nope doesn't matter at all what chipset you use - in order to conform to the BTLE spec no device advertising non-connectably (or scannable) can advertise faster than once every 100ms.

I assume as part of the certification process for Nordic (and everyone else's) bluetooth stack there's a test that the stack rejects invalid parameters like that.