How do I minimize the number of connection messages sent?

[Rory Morrison]

I'm looking at a BLE application using the nRF51822 where we need to send data maybe once every 10 minutes, so it seems like disconnecting in between sending messages will save a lot of battery life. However, each time a connection is made, in between advertising and the actual data transfer, there are a whole bunch of L2CAP messages being sent at about 25 ms intervals.

I haven't yet worked out exactly what they're for, but it seems like they're to do with negotiating the connection parameters and/or synchronizing between the devices. Many of them have the data type L2CAP-C, with no actual data being sent, and some of them contain link layer commands.

I assume they are unavoidable, but what can I do to minimize the number of messages being sent? Failing that, what exactly are they, and what are they for?

Thanks in advance!

[Carles]

I'm not quite sure what you mean by traces, but this is what I get using a packet sniffer:

Yes, I meant the output of a sniffer.

LL_Version_Ind ATT_Read_By_Type_Req LL_Version_Ind LL_Incryption_Req ATT_Read_By_Type_Rsp LL_Encryption_Rsp LL_Reject_Ind ATT_Read_By_Type_Req ATT_Error_Response ATT_Write_Req ATT_Write_Rsp ATT_Read_Req ATT_Read_Rsp ATT_Read_Req ATT_Read_Rsp ATT_Read_Rsp ATT_Write_Req ATT_Write_Rsp ATT_Read_Req ATT_Read_Rsp ATT_Write_Req ATT_Write_Rsp

Service Discover, not necessary to do this every time?

ATT_Handle_Value_Ind ATT_Handle_Value_Confirm

The actual data exchange. You could disconnect after this.

...Lots of blank messages... (~300)

SIG_Connection_Param_Update_Req LL_Connect_Update_Req SIG_Connection_Param_Update_Rsp

...some more blank messages... (only 10 or so)

A connection Parameter Update, you don't need this if you've already sent the data you wanted with the Handle Value Indication.

LL_Terminate_Ind

The disconnection.

So it looks like that's the service discovery being done, then a wait for the connection parameter update to happen, then I assume LL_Terminate_Ind means something like "Stop service discovery and wait for indications".

No, it means "disconnect now".

I don't know how much of this is set by the peripheral end of the connection - for example, maybe the blank messages could be eliminated if the control app responded faster? At the moment I'm using a modified version of the Temperature sensor example code, and the Nordic iOS app, but we are working on our own BLE app for Android, so we will be able to control both ends of the connection.

The service discovery is being performed (I assume) by the central, since you are most probably acting as an ATT server. You will need to optimize the phone side no to do that every time (bonding and then relying on Service Changed).

Would enabling bonding be the best way to eliminate the service discovery, or are there other ways to do that? And is the delay most likely to be coming from the Central, or the Peripheral?

Yes, bonding should eliminate the whole discovery procedure. The delay is caused by you not disconnecting immediately after the Handle Value Confirm, which I believe you should do if all you want is to send a value from peripheral to central. Either the peripheral or central could trigger that disconnection.

[Carles]

BLE_GATTS_EVT_HVC is the event ID for a handle value confirmation, which is an indication acknowledgement.

Disconnecting after you receive the confirmation sounds like the right thing to do in your case.