Need long battery life with fast connection interval

We need fast response from peripheral to central. That means we need a fast connection interval. We are using less than 100mS. But that results in an unacceptable battery life. We are trying different strategies to address this problem. One idea is to have a longer connection interval after some period of non-use. But this takes several seconds to renegotiate the connection parameters. Anyone got some idea about this?  I would think this is a common problem that has a solution.

Parents
  • Hi

    Have you checked out my colleague Scott's current consumption guide where he goes through all the most common ways to optimize power consumption on nRF52 designs? The connection interval should not be detrimental to your current consumption, so please check out the guide for some suggestions. What is I.E. the connection supervision timeout in your application and advertising interval?

    Best regards,

    Simon

  • Yes we are trying slave latency. For some of the peripherals, its fine, because they do not receive data, only send as required. We've got another peripheral however, that will need to receive data. So we are thinking about some scheme where maybe we can adjust the slave latency depending on how often its used. If there is for example, 1 hour of non-use, then we increase the latency. That will result in a small delay, or maybe even a missed command, but that's ok. After some activity then the latency goes back to 0 until there is another lapse in use.

    We can't have some of the devices go to sleep, because they are not easily accessible. We must maintain some connection.

Reply
  • Yes we are trying slave latency. For some of the peripherals, its fine, because they do not receive data, only send as required. We've got another peripheral however, that will need to receive data. So we are thinking about some scheme where maybe we can adjust the slave latency depending on how often its used. If there is for example, 1 hour of non-use, then we increase the latency. That will result in a small delay, or maybe even a missed command, but that's ok. After some activity then the latency goes back to 0 until there is another lapse in use.

    We can't have some of the devices go to sleep, because they are not easily accessible. We must maintain some connection.

Children
  • So we are thinking about some scheme where maybe we can adjust the slave latency

    Hmm.. Is there a way to tell the BLE stack to wake up on every interval even if you have a nonzero slave latency? Because as far as I know the only way to really adjust it is to renegotiate the connection parameters. And that undoes much of the benefits.

    If your device also sends some data to the central, then one option is to send dummy notifications. So keep a large slave latency all the time. And when you do want to wake up on every interval, send a dummy notification to force the peripheral to wake up.

  • I don't totally understand this. If the peripheral has a high latency, it won't be listening for data from the central. Am I wrong? I guess what we need is some way to force the peripheral to "override" the latency.

  • Yes, that's what I was trying to say.

    I'm not sure if there is a way to tell the Nordic BLE stack that you would like it to listen on every interval even if you have negotiated a high slave latency.

    But one way to override this is to have something to send from the peripheral to the central. So when you'd like to override the latency, send a dummy notification from the peripheral every 100ms. That forces the peripheral to listen.

    This would mean some extra communication, but it would avoid the need to renegotiate.

Related