BLE discovery failure

[pranesa]

Hi Team,

We have seen 10 instances in past 2 months where customer mobile phones failed to discover BLE device. This has happened 8 times with Moto G7 power (Android) and twice with iPhone mobile phones. We were able to reproduce this issue locally by streaming music over Bluetooth on Samsung Galaxy S20+ mobile. Same phone was able to discover and connect to device when music is turned off. Hence we are thinking that this issue is not due to BLE Tx power. It seems to be more related to coex mechanism on the phones.

As of now, the BLE advertisement interval is set to 300ms on device. We were thinking of using Burst advertisement mechanism on device to overcome this problem. Rather than sending one BLE advertisement every 300 ms, we can have multiple events, say 5 or 10, sent every 20 ms and then repeat it after 1 second. Can you please let us know how we can achieve this with SoftDevice? Also, feel free to suggest any other fix to solve this problem. 

Thanks,

Pranesh

[Einar Thorsrud]

Hi Pranesh,

It sounds like maybe what is happening here is that when the phone is streaming audio over Bluetooth, there is less time to do scanning. And then most likely, the advertising events of the peripheral does not overlap with the scan window of the phone.

It is possible to do as you suggest, but we usually recommend to follow Apple's recommendations here, which typically work well also with other devices. Their recommendation is specified in section 36.5 in Accessory Design Guidelines for Apple Devices R13. Specifically:

What apple suggests here is supported by the advertising module, which typically starts of first with fast advertising, and then after a specified amount of time enters slow advertising.

The method you suggest, by using bursts of fast advertising, then waiting and doing bursts again is not explicitly supported by the advertising module. However, there is nothing preventing you from implementing it by simply configuring fast advertising, and then stoping and starting advertising regularly. Assuming you use the advertising module you configure and start it as normal, then stop it by calling sd_ble_gap_adv_stop(). Then after a designated time start advertising again by calling ble_advertising_start().

Einar

[pranesa]

Hey Eniar,

Thanks for helping us with this issue. We did one experiment locally with advertisement interval set to 20ms instead of 300ms which is set in production. We were able to repro the issue again.

Many different customer interact with our product on a daily basis. They have different types of mobile phones. Apart from changing advertisement interval and implementing burst advertisement, do you have any other suggestion to resolve this issue? Please let me know if you need any more information.

[pranesa]

Sorry for the delay in response. Please find my answers below:

>> Have you logged on the nRF side to see if there is a connect and then a subsequent disconnect, or does the phone never attempt to connect in this state?

The phone fails to discover the device hence we don't see any connection or disconnection activity on device.

>>Which LF clock source do you use? internal RC or external crystal?

We use external crystal. NRF_SDH_CLOCK_LF_ACCURACY is set to 7 which translates to 20ppm.

>> How have you configured the clock parameters? If you use a crystal, then it would be good to see your schematics and layout and know the value of the load caps

We haven't done any specific tuning to the clock parameters hence they must be at default values. Can you please let me know the exact configs (clock params and load caps) you want to look at? I will find out schematics and layout in the meantime.

Thanks again for helping us out.

[Einar Thorsrud]

Hi,

pranesa said:

We haven't done any specific tuning to the clock parameters hence they must be at default values. Can you please let me know the exact configs (clock params and load caps) you want to look at? I will find out schematics and layout in the meantime.

I need to know the exact 32.768 crystal part number you use and the value (in pF) of the two load caps. A typical reason for issues like this is a inaccurate LFCLK due to wrongly calculated load capacitors.

[pranesa]

[pranesa]

Hi Einar,

I have attached the external crystal part details and schematics. Please let me know if you need more details.

Thanks

[pranesa]