BLE discovery failure

RE: BLE discovery failure

Einar Thorsrud — Mon, 18 Jan 2021 13:25:46 GMT

Hi Pranesh,

[quote user="pranesa"]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[/quote]

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.

[quote user="pranesa"]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?[/quote]

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

RE: BLE discovery failure

pranesa — Sun, 17 Jan 2021 04:56:13 GMT

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?

RE: BLE discovery failure

Einar Thorsrud — Tue, 12 Jan 2021 10:01:29 GMT

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.

RE: BLE discovery failure

pranesa — Tue, 12 Jan 2021 09:31:13 GMT

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

RE: BLE discovery failure

Einar Thorsrud — Tue, 12 Jan 2021 09:02:01 GMT

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

RE: BLE discovery failure

pranesa — Tue, 12 Jan 2021 08:58:16 GMT

Hey Einar,

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

RE: BLE discovery failure

Einar Thorsrud — Tue, 12 Jan 2021 08:18:29 GMT

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

RE: BLE discovery failure

pranesa — Tue, 12 Jan 2021 07:10:47 GMT

RE: BLE discovery failure

pranesa — Tue, 12 Jan 2021 02:56:39 GMT

Hi Einar,

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

Thanks

RE: BLE discovery failure

pranesa — Tue, 12 Jan 2021 02:55:50 GMT

RE: BLE discovery failure

Einar Thorsrud — Mon, 11 Jan 2021 15:56:28 GMT

Hi,

[quote user="pranesa"]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.[/quote]

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.

RE: BLE discovery failure

pranesa — Mon, 11 Jan 2021 15:25:28 GMT

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.

RE: BLE discovery failure

Einar Thorsrud — Tue, 22 Dec 2020 10:12:43 GMT

Hi Pranesh,

If the nRF advertises with an advertising interval of 20 ms and the phone is still not able to connect then there must be another issue. Either the phone has no or virtually no time for scanning, or another possible explanation could be issues with the LF clock. If the LF clock is too inaccurate, it may be difficult to establish and maintain connections.

I suggest we look into the LF clock part first. If that is not the problem, at least it has been ruled out. 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? Which LF clock source do you use? internal RC or external crystal? 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.

Note that I will be of on holiday the rest of the year, so I may not be able to reply again until beginning of January.

Einar

RE: BLE discovery failure

pranesa — Tue, 22 Dec 2020 06:28:50 GMT

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.

RE: BLE discovery failure

Einar Thorsrud — Fri, 11 Dec 2020 12:31:08 GMT

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