This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How do I minimize the number of connection messages sent?

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!

Parents
  • I'm not quite sure what you mean by traces, but this is what I get using a packet 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 ATT_Handle_Value_Ind ATT_Handle_Value_Confirm

    ...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)

    LL_Terminate_Ind

    There are blank messages with the L2CAP-C header in between the other messages; presumably they're just placeholder messages.

    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".

    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.

    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?

    Thanks,

    Rory

Reply
  • I'm not quite sure what you mean by traces, but this is what I get using a packet 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 ATT_Handle_Value_Ind ATT_Handle_Value_Confirm

    ...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)

    LL_Terminate_Ind

    There are blank messages with the L2CAP-C header in between the other messages; presumably they're just placeholder messages.

    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".

    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.

    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?

    Thanks,

    Rory

Children
No Data
Related