nRF52833 stream notifying BLE packets get stuck frequently

RE: nRF52833 stream notifying BLE packets get stuck frequently

Susheel Nuguru — Mon, 02 Jan 2023 05:57:16 GMT

[quote user="Juergen Laude"]"bt_gatt_notify" unfortunately waits until the buffer gets space again, a return code would be nice[/quote]

I agree, this has been asked by few before, so I will check with the R&D team if we can make this purely asynchronous with an error when no buffer is available.

[quote user="Juergen Laude"]I will test more on using RC for LFCLK especially because of the limitation "DRGN-6362: Synthesized low frequency clock source not tested".[/quote]

sounds like a plan. Thanks for letting me know.

RE: nRF52833 stream notifying BLE packets get stuck frequently

Juergen Laude — Thu, 29 Dec 2022 18:51:50 GMT

Problem almost solved: While movement lots of packets get lost and BLE TX buffer fills-up. "bt_gatt_notify" unfortunately waits until the buffer gets space again, a return code would be nicer. Could't find a function to request the current fill level, so I have to count from outside.

Forcing the connection interval to 15 msec (default 30 msec) seems to give more chances to re-transmit lost packets.

I will test more on using RC for LFCLK especially because of the limitation "DRGN-6362: Synthesized low frequency clock source not tested".

RE: nRF52833 stream notifying BLE packets get stuck frequently

Juergen Laude — Wed, 28 Dec 2022 13:08:47 GMT

"Stuck" means the call to "bt_gatt_notify()" does not return although the mobile app tries to receive the notifications.

For internal RC for LFCLK we had:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=y

do we need more?

RE: nRF52833 stream notifying BLE packets get stuck frequently

Susheel Nuguru — Wed, 28 Dec 2022 09:55:30 GMT

We need to get more context on what the state of "Stuck" means in this issue.

[quote user=""]

This went away when using SYNTH instead (maybe this helps for diagnosing the problem).

[/quote]

Using internal RC for LFCLK might not be good enough for the accuracy of the BLE connection timekeeping. If you are using RC for LFCLK they frequently needs to be calibrated based on the HFCLK Crystal or you need to use SYNTH LFCLK derived from hfclk itself.