Proper S110 cleanup on link loss/disconnect?

[Mike Wirth]

Folks, Here's a specific question and a larger question, of which the first is a part.

1. What's the proper way to insure S110 BLE stack cleanup on disconnect due to link loss, especially so I can quickly restart advertising to reestablish the connection?

2. Is there a document on "link management", i.e., handling link connections, reconnection attempts, possible peer error states, with or without bonding, etc., to try to keep two devices connected in as robust a way as possible?

Context: I'm using the S110 stack, version 5.1 on an nRF51822 (production version C0, IIRC) and SDK 4.4.2 (limited to this version by the IC prod. version). BTW, tried the version 6.0 stack but failed (probably because I didn't go through the migration instructions). Communicating with an iPhone 5, running iOS 7.1 and the current Core Bluetooth framework.

Problem: When the connection is running stably for awhile, I cause a disconnect (either by moving out of range or by killing the iPhone app). S110 senses disconnect and issues BLE_GAP_EVT_DISCONNECTED event, which my app picks up and sets the saved connection handle variable to BLE_CONN_HANDLE_INVALID. I use this to realize that I'm no longer connected and attempt to go back into advertising mode by regenerating the advertising params structure and calling sd_ble_gap_adv_start again. But it fails with error 8: "NRF_ERROR_INVALID_STATE Invalid state, operation disallowed in this state". So I'm clearly missing some cleanup step.

I've tried making sure the app-task/event queue is empty by running app_sched_execute() before starting advertising again, delaying 1 sec. to give the stack time to settle, both to no avail. BTW, is there an easy way to inquire as to the current state of the stack? I must have missed it.

Any comments and help appreciated,

Mike

[Pål Håland]

Hi Mike, Just a small comment. Do you have a different flag to disallow calling the sd_ble_gap_adv_start twice right after each other? It looks like you have only one flag to determine if you should start advertising again, and this flag will not be updated until you have a connection. In the connection event.

It would probably be an idea to have a BLE_CONN_HANDLE_INVALID and BLE_CONN_HANDLE_ADV_STARTED or something, and only trigger advertising on the BLE_CONN_HANDLE_INVALID, and then update it to BLE_CONN_HANDLE_ADV_STARTED?

BR Pål

[Mike Wirth]

Pål, Thanks for the feedback. At the app level, I have an FSM (Finite State Machine, implemented by a switch statement in C), so I shouldn't be calling advertising start multiple times. But there might be something happening at lower levels. I'll check. BTW, what's the S110 behavior if it loses connection and signals that to the app, causing the connection handle to go invalid, but goes back in range before the central tears down the connection. Will the S110 reconnect by itself? (Is this a possible situation? Too many error states and recovery paths to consider :-) Mike (who's going off to read the "best practices" section in the iOS Core Bluetooth documentation on link maintenance)

[Pål Håland]

When the S110 disconnects and signals that to the application, then it is no longer in a connection. Thus what you are asking about will never happen. At that point it is up to the app developer to either put it to sleep or start advertising again. As the S110 is just a peripheral device, the only thing it can do (as the iPhone don't support directed advertising) is to just do normal advertising again. For how to handle the reconnection on iOS, I have no clue about.

[Mike Wirth]

Just to follow up and close this question: Problem solved. Pål was on the right track. I wasn't making a redundant call to start advertising, but after the new connection was established I was attempting to restart RSSI-changed events and the call was failing because it was already started (didn't get shutdown when the prior connection went away and survived through the disconnect and reconnect).

At this point, I would make a plea for a general "feature" in the S110 Soft Device -- it would be great to have a way to ascertain the current state of the BLE stack. In particular, any configuration change that's written to the soft device should be readable.

In the current case, if I ask to start RSSI-changed events, at some other point in my code it would be great to be able to determine the state of this activity. Without that, I had to write test code to determine that the call to start it while already running failed, but redundant calls to stop it didn't. Therefore, a defensive programming style is to always turn the activity off before starting it up. Seems kind of silly.

Thanks again,

Mike