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.

[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]

[Einar Thorsrud]

Hi Pranesh,

I see your load caps (C27 and C32) are 18 pF. The datasheet of the crystal shows that it exists with both 6, 9 and 12.5 pF load capacitance. I would need the exact part number to know which variant you have. Can you get that for me?

If you have the part with 12.5 pF (STD-MUA-8), then 18 pF load cap values are good (rule of thumb is C1 = C2 = 2Cl - C_pcb - C_pin, where C_pcb + C_pin is approximately 4 pF).

Einar

[pranesa]

Hey Einar,

We are using STD-MUS-2, confirmed by our manufacturer.

[Einar Thorsrud]

I see. That is also 12.5 pF so it should be good.

[pranesa]

ok, do you see any issue with clock accuracy setting (20 ppm)? or is there any other setting that we should look into?

[Einar Thorsrud]

Hi,

The crystal is specified at 20 ppm, so that should be fine. You could configure a higher clock accuracy to get more margin, but this is probably not the root cause of what you are seeing.

Reading the case again I recall you only see this issue on some phones, and only when they also have BLE audio connection active. This would lead to less time to do scanning, so I suspect that is the problem here. Either the phone does not scan at all, or the scan window is short and occurs quite celdom, or it just co-varies in an unfortunate way with the advertising interval on the nRF. If that is the case, the only thing you can do is to reduce the advertising interval and see if that helps. As mentioned you should also pick an interval that is in line with Apple's recommendations, which also typically work well with Android devices.

[pranesa]

Hey Einar,

We have collected more data around this issue, it is now being seen with other device model as well. We plan to do the following:

1. Move to 152.5ms advertisement interval from 300ms. 

2. Start an SOP to capture more info on other devices in the BLE environment using nRF connect app.

3. Increase discovery timeout on mobile apps from 6 secs.

We will capture data again after these changes are deployed to production fleet. In the meantime, we have got the recommendation from our wireless technology team to use burst advertisement to solve this issue. We want to send multiple adv. events, say 5 or 10, sent every 20 ms and then repeat it after 1 second. This can't be implemented by us since we have access to start and stop APIs only, we don't have control on number of packets sent in a window. Can Nordic implement burst advertisement for us? or is it part of Nordic's roadmap?