• State Verified Answer
  • Replies 5 replies
  • Subscribers 73 subscribers
  • Views 2103 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 110846
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BTLE_CONNECTION_TIMEOUT while connection interval is small

zhao

Hi experts,

I need nrf51822 to send thousands of packets (notification) to Master Control Panel (PC), and expect for high data rate. So, I turned the connection interval from 100 ms to 20 ms in Master Control Panel. Unfortunately, the connection is broken after about 5 seconds. Everything is ok if the connection interval is 100ms.

my device configuration is like #define MIN_CONN_INTERVAL MSEC_TO_UNITS(10, UNIT_1_25_MS) #define MAX_CONN_INTERVAL MSEC_TO_UNITS(200, UNIT_1_25_MS) #define SLAVE_LATENCY 10
#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(5000, UNIT_10_MS)

It seems the reason of timeout is I can't send packets as soon as possible. While the connection interval is 20 ms, the actual data rate is about 30 packets per seconds. The low data rate should be because I need read data from SPI Flash for sending.

I'm very confused why it happened. If I didn't send any notification, the connection was always on; but it timeout if I sent notification not fast enough.

Wondering for your help!

Parents
  • 0

    Ok. When the central writes to the peripheral SPI fetches some data from an external flash and send it to the central with notifications. It seems you are not using interrupts, so the the SoftDevice should be able to interrupt any operation, including SPI, to maintain the connection. Could it be that an error is sent to app_error_handler() somewhere? And this resets the chip? Try putting a breakpoint in app_error_handler(). ble_flash.c is for accessing the internal flash of the nRF5, but you have an external flash if I have understood you correctly. With regards to your other experiment, maybe you fill are filling up the complete RAM space?

Reply
  • 0

    Ok. When the central writes to the peripheral SPI fetches some data from an external flash and send it to the central with notifications. It seems you are not using interrupts, so the the SoftDevice should be able to interrupt any operation, including SPI, to maintain the connection. Could it be that an error is sent to app_error_handler() somewhere? And this resets the chip? Try putting a breakpoint in app_error_handler(). ble_flash.c is for accessing the internal flash of the nRF5, but you have an external flash if I have understood you correctly. With regards to your other experiment, maybe you fill are filling up the complete RAM space?

Children
No Data
Related
Terms of service