BLE timeout when SAADC sample rate is high

RE: BLE timeout when SAADC sample rate is high

Karl Ylvisaker — Tue, 24 Aug 2021 11:14:34 GMT

[quote user="StevenW807"]Thanks for your help, Karl.[/quote]

No problem at all, I am happy to help!

Thank you for providing the sniffer traces, this makes it a lot easier for me to see what is happening.
It seems to me that your peripheral device abruptly stops responding in the unstable trace - this is very helpful for debugging purposes.
This behavior makes me suspect that the device might be encountering an error that causes it to reset, could this be the case?
Are you able to monitor what is happening on the peripheral side of the link when this behavior occurs?
I see from your included main.c code that you are initializing the logger. Are you seeing the logger's RTT output? You should be able to see this either in the SES Debug terminal or in the standalone SEGGER RTT Viewer desktop application.

Based on the information we have so far I am suspecting that the increased sampling rate is causing a buffer to overflow, which in turn resets the device.
The default error handling of the APP_ERROR_CHECK is to reset the device, so unless you have implemented specific error handling for it this is what will happen whenever a non-NRF_SUCCESS error code is passed to an APP_ERROR_CHECK.

Please make sure to have DEBUG defined in your preprocessor defines for the common build configuration like described in my initial reply, and check what the RTT log reads when this behavior occurs. Please let me know what the logger says.

Looking forward to resolving this issue together!

Best regards,
Karl

RE: BLE timeout when SAADC sample rate is high

StevenW807 — Mon, 23 Aug 2021 06:09:35 GMT

Thanks for your help, Karl.

I used Nordic UART Service --> Tx Characteristic in nRF Connect App to receive BLE data. When SAADC interrupt time = 50ms, both BLE advertising and receiving data are very stable. It will never disconnect.

However, if I change to SAADC interrupt time = 20ms, BLE advertising and connection are very unstable. BLE advertising and connection are fine. But after selecting receiving data, BLE will disconnect automatically after 1-20 seconds. The Error message is: Error 8 (0x8): GATT CONN TIMEOUT. Because in 50ms SAADC interrupt case, BLE works fine. So I think that my code has no problem.

In my code, I used TWI, SAADC (PPI interruption), UART and BLE. I used the internal clock, clock calibration in SDK is configured.

I used the nRF52 DK as the BLE sniffer. Here are 2 sniffer log files:

Sniffer 1) stable BLE connection (50ms SAADC interrupt)

Sniffer 2) unstable BLE connection (20ms SAADC interrupt)

Thank you very much!

devzone.nordicsemi.com/.../Unstable-BLE.pcapng devzone.nordicsemi.com/.../Stable-BLE.pcapng

RE: BLE timeout when SAADC sample rate is high

Karl Ylvisaker — Mon, 16 Aug 2021 15:06:57 GMT

Hello,

Thank you for your continued patience with this. I have been out of office for some time now, but now I am back.

[quote user="StevenW807"]Thank you so much for your detailed support, Karl! [/quote]

No problem at all, I am happy to help!
Thank you for elaborating.

[quote user="StevenW807"]BLE seems to be very unstable (BLE will disconnect after 2-20 seconds).[/quote]

What do you mean what you say unstable? What reason do you get for the disconnect?
Could you possibly provide a sniffer trace of the on-air BLE traffic when this happens? You could use the nRF Sniffer tool to capture this trace.

[quote user="StevenW807"]

I have read another post on a Chinese website. The author says that the reason is: Device hasn't completed transmitting the current data, and the device tries to send another new data. The solution is to add a flag in BLE. The device only allows sending the next data until the previous data has been sent successfully.

Do you support his/her opinion? How to add this "BLE transmitting is completed flag", please?

[/quote]

This will not be the case when working with the SoftDevice. The SoftDevice handles all this for you, behind the scenes. What I could imagine might be happening is that the SoftDevice returns an error code (non-NRF_SUCCESS) to the application after a function call, and that the application then resets due to this error, thus disrupting the BLE connection and everything else. Could this be the case?

Best regards,
Karl

RE: BLE timeout when SAADC sample rate is high

StevenW807 — Tue, 27 Jul 2021 11:56:28 GMT

Thank you so much for your detailed support, Karl!

My SAADC uses timer1 and PPI to generate interruption every XXX ms. If 50ms, my BLE works perfectly fine. However, if I shorten the interruption time, for example 10ms, BLE seems to be very unstable (BLE will disconnect after 2-20 seconds). I only send a very small amount of data (about 10-15 bytes) every time.

Do you support his/her opinion? How to add this "BLE transmitting is completed flag", please?

Thanks, Karl!

RE: BLE timeout when SAADC sample rate is high

Karl Ylvisaker — Fri, 16 Jul 2021 14:28:12 GMT

Hello,

[quote user=""]1) Does the error caused by BLE MTU, or SAADC dual Buffer, or something else? [/quote]

I am not sure what you are asking here, are you getting an error? If so, what error is generated?
Please make sure to have DEBUG defined in your preprocessor defines, like shown in the included image, to have the logger output a detailed error message whenever a non-NRF_SUCCSS error code is passed to an APP_ERROR_CHECK.

EDIT: I see now that you say you are getting a GATT timeout error. This means that your connection times out - i.e the central or peripheral is not hearing from its peer in the time configured as the timeout. Are the devices still within range? Is both devices always powered on?

[quote user=""]2) If I set SAADC buffer = 4 and 4 channels, does that mean SAADC will save the past 4 data in the 4 channels (in total 16 data), and give return averaged data for 4 channels?[/quote]

No, if you set SAADC buffer to 4, it will be big enough to contain 4 samples.
If you are using the SAADC in scan mode, it will sample once from every enabled channel each time the SAMPLE task is triggered, which will then produce 4 samples, immediately filling up the buffer.
If you would like the SAADC to average over a number of samples you will have to enable oversampling on the channels. Please be advised that oversampling must be configured together with burst mode, in order to work when the SAADC is in scan mode.

[quote user=""]3) I use the timer to interrupt SAADC. For each interrupt, there will be only 1 SAADC reading. If SAADC_SAMPLE_RATE = 250ms and buffer = 4, does that mean SAADC returns the data at 1 second ago (250ms*4 = 1sec)? [/quote]

No, each time SAMPLE is triggered it will sample all enabled channels, which here is 4. 4 samples will therefore be generated every sampling.

[quote user=""]4) BLE min/max connection interval is 10ms to 20ms. If my SAADC timer interrupts every 250ms, what data will BLE send during most of the connection intervals? Just empty packages?[/quote]

Yes. If there is no data to be sent when a connection event is upcoming both devices will send an empty packet to maintain the connection. In these cases you should either increase your connection interval, or make use of the slave latency feature in order to save power.

[quote user=""]5) If the BLE min/max connection interval is 10ms to 20ms, and my SAADC timer interrupts every 5ms, does that mean there will be 2-4 packets (Rx+Tx is 1 packet) for each connection interval? [/quote]

This depends on your connection event length configuration. If there is more packets to send, the devices will keep on sending packets for the entire duration of the configured connection event length. You can use the Online Power profiler to see how different size TX payloads are transferred depending on the configured connection event length and connection interval.

[quote user=""]6) My custom board uses an internal RC oscillator (32.768kHz), Why does SAADC uses NRF_TIMER_FREQ_31250Hz, but not 32.768kHz? [/quote]

The TIMER peripheral uses the HFCLK, not the LFCLK. The frequency therefore have to be a multiple of the HFCLK frequency, since the lower frequencies are implemented by prescaling the HFCLK tick rate. You can find the available prescaler values here.

Best regards,
Karl