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]

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?

[Einar Thorsrud]

Hi Pranesh,

pranesa said:

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

Reducing the advertising interval and increasing the timeout time on the phone seems very sensible. Regarding the burst advertising I think no matter what changes you make it is difficult to know if it would improve the situation or not without knowing the scan pattern of the phone when you see this issue. So while I understand that you want to try this approach, I do not immediately understand why it would improve the situation.

pranesa said:

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?

Does the nRF have any other connections active at this stage, or is the only radio activity to advertise? If so, then you can count advertising packets by using radio notifications which is an API that exists in the SoftDevice today.

Also, I wonder if you really need to know the exact amount of advertising packets? If not, you could just configure advertising with a high duty cycle and keep that for some time, and then reconfigure after the elapsed duration. As you know, a random delay of 0-10 ms is added after a advertising interval, so on average, the time between advertising packets would be the specified advertising interval + 5 ms. So if you advertise for 1 second with 20 ms advertising interval, you would on average get 1000 ms / (20 ms - 5 ms) = 66.67 advertising events. Multiplied by 3 for each channel, that would mean 200 advertising packets.

Einar