Proper S110 cleanup on link loss/disconnect?

RE: Proper S110 cleanup on link loss/disconnect?

Mike Wirth — Fri, 01 Aug 2014 18:12:42 GMT

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

RE: Proper S110 cleanup on link loss/disconnect?

Pål Håland — Tue, 29 Jul 2014 05:44:46 GMT

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.

RE: Proper S110 cleanup on link loss/disconnect?

Mike Wirth — Mon, 28 Jul 2014 19:57:40 GMT

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)

RE: Proper S110 cleanup on link loss/disconnect?

Pål Håland — Mon, 28 Jul 2014 09:11:38 GMT

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