NRF51822 disconnects connection after 1 min

[Pim]

I'm using a custom designed PCB around the NRF51822 that broadcasts accelerometer readouts on a characteristic. The application is based on s110 uart example and has been working fine. However, I am experiencing connection issues with a specific program on my PC.

Using either Apple's Bluetooth Explorer or an iPad application such as BLE Tool (itunes.apple.com/.../id525235616 I have no trouble connecting and setting a notify on the ACC characteristic. Whenever the device is rotated or turned the ACC value updates and the connected application receives an notify.

On the PC i'm using Noble (a node.js BLE implementation) that also works fine. However, only for the first minute. After around 60 seconds the connection is disconnected. From debugging the NRF I have found that the reason for the disconnect is 0x16 (LOCAL_HOST_TERMINATED_CONNECTION). So apparently the NRF initiates the disconnect. According to here (devzone.nordicsemi.com/.../) the reason could be a L2Cap connection parameter update timeout or a pairing failure.

Is there any way to find out the specific reason for the disconnect? Or is it possible to ignore the L2Cap connection parameter update timeout? Everything works fine in the first 60 seconds so I would be perfectly happy if I can just let the connection stay alive.

I have captured two debug sessions with Wireshark: NRF51822-Noble-debug-session.zip One between the NRF and Noble and one between NRF and the iPad application. I am not able to see what is different in the connection but maybe you guys are able to :)

Thanks in advance for your time!

[Ole Bauck]

I suspect that the reason has to do with parameter update request not being answered by the master. I see from the wireshark cap that the disconnect happens almost accurately 60s after connection parameter update request is sent. What is your update delay and update count used in conn param module?

You can also check where the disconnect is called by searching for sd_ble_gap_disconnect, set a breakpoint at each and run the application in debug mode.

A tip with wireshark: Remove all the empty packets by typing "btle.data_header.length != 0" in the filter field.

[Pim]

Thank you Ole for the quick reply! I think that you are right and that this is indeed the case. My settings are as follows, I did not make a change, they are the same as in the example: #define FIRST_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(5000, APP_TIMER_PRESCALER) #define NEXT_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(30000, APP_TIMER_PRESCALER) #define MAX_CONN_PARAMS_UPDATE_COUNT 3

I only find sd_ble_gap_disconnect twice, once in static void on_conn_params_evt(ble_conn_params_evt_t * p_evt) and once in void bsp_event_handler(bsp_event_t event). Both are not fired during a debug session with a breakpoint attached.

I don't think it is possible to make the master respond to the update request. Would it be possible to disable the request altogether on the NRF? Of just ignore the fact that no answer is received so that it will not disconnect?

[Ole Bauck]

There is also one in static void update_timeout_handler(void * p_context) in ble_conn_params.c. You can disable the connection request by not calling conn_params_init() in main.

[Pim]

Wauw, thank you so much! Removing the call to conn_params_init() solved the issue :) Just out of curiosity: does this have any negative effects on the long term?

[Ole Bauck]

Connection parameter update request is implemented to allow the peripheral to request connection parameters that makes it use the least amount of power, as the peripheral most often has limited power (small battery) and the central has more power (large battery). Removing the conn_param module will make the central in full charge of the connection parameters, while the peripheral have nothing to say. See this post for more.