• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 52 subscribers
  • Views 1583 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2642R: Unexpected Connection Events with non-zero Slave Latency

Alexander Wenner
Intellectual 420 points
Part Number: CC2642R


Hi.

Our project is based on the simple_peripheral project from SDK 4.20.00.35.

We are using connection parameters with a connection interval of 100-150ms and a slave latency of 10, because we want the peripheral to easily switch between mostly sleeping and transmitting decent amounts of data. In idle phases (the peripheral is sending no data) we observe that the peripheral will mostly exploit the full slave latency and connection events occur every 1-1.5s. However sometimes we see multiple connection events close together. We were able to determine that these multiple events coincide with the central sending a LL_CHANNEL_MAP_IND PDU. The peripheral then also wakes for the next connection event sending an empty PDU. We have observed some centrals sending LL_CHANNEL_MAP_IND PDUs every 10s, leading to ~10% more power consumption than expected in this situation due to the additional connection events.

In the context of these observations it would be nice if you could answer the following questions:

  1. Is there any particular reason for the additional connection events? As far as I can tell, the SIG does not seem to specify a response to a LL_CHANNEL_MAP_IND PDU. Or does the BLE5 Stack use the connection event to prepare the new channel map? Could this be optimized to happen before the next "necessary" connection event instead?
  2. Are there any hard criteria for when the BLE5 Stack will seize a connection event and when it will skip it? E.g. PDU queue not empty.

We have also looked at switching between fast and slow connection parameters for guaranteed intervals instead of using the slave latency. However there can be long (multiple seconds) delays during negotiation of new parameters which make the experience suboptimal in contrast to simply using slave latency.

Sincerely,

Alexander Wenner

  • 0
    TI__Mastermind 25810 points

    Hey Alexander,

    I've assigned this to an expert to comment.

  • 0 in reply to Ammar N
    TI__Genius 17265 points

    Hi Alexander,

    Are you able to send a BLE sniffer log that shows what you are seeing? This will help me to better understand your issue.

    Best Regards,
    Alec

  • 0 in reply to Alec May
    Intellectual 420 points

    Hi.

    I was able to get some sniffing done using the SmartRF Packet Sniffer 2, hope it helps. The master device in this case is a Redmi Note 9 Pro smartphone and the slave latency is set to 10 in the parameter update in frame 468. Frame 637 and following are an example of the behaviour I was describing. Following the last realized connection event 370 in frame 625/626, as expected the peripheral sits out the next 10 events until connection event 381 in frame 637 starts. Here some empty PDUs and a LL_CHANNEL_MAP_REQ PDU are exchanged and the event ends in frame 640. I would now expect the peripheral to again skip the next 10 events, however it already responds in event 382 in frame 641/642.

    channel_map_slave_latency.pcapng.gz

    Sincerely,

    Alex

  • 0 in reply to Alexander Wenner
    TI__Genius 17265 points

    Hi Alex, 

    Please give me some time to go through this sniffer data and look through some of our documentation. I will get back to you before close of business on Tuesday.

    Best Regards,
    Alec

  • 0 in reply to Alec May
    TI__Genius 17265 points

    Hi Alex,

    After reviewing the BLE core specification, I think you should look at your Central device's channel map update procedure. You can look the update procedure in BLE core specification version 5.1 Vol 6 Part B Section 5.1.2. In this section, it describes that the Central is responsible for determining when to send these updates, so I think it may be best to start by looking at your central device for clues. Let me know if there's anything else that I can answer for you.

    Best Regards,
    Alec

  • 0 in reply to Alec May
    Intellectual 420 points

    Hi Alec,

    thank you for looking into this. I've read through the section of the core specification you referenced and I am still not able to explain why the peripheral does not start immediately exploiting slave latency after a LL_CHANNEL_MAP_IND was received, but also activates during the immediately following connection event. We have tried multiple different central devices and the behaviour occurs with each of them.

    Also it would still be nice to know in general when the TI Stack will override slave latency and activate for a connection event, even if my application did not queue any data to be send to the central.

    Sincerely,

    Alex

  • 0 in reply to Alexander Wenner
    TI__Genius 17265 points

    Alex,

    I see, I misunderstood your issue a bit. I'm going to confer with someone on my team on Monday and get back to you.

    Best Regards,
    Alec

  • 0 in reply to Alec May
    TI__Genius 17265 points

    Alex, 

    My sincerest apologies for the delay. I've been trying to find any of our documentation that specifically addresses this, and haven't had such luck. I am in discussions with a few other BLE experts to try to get this answer for you. I should have an update for you shortly.

    Best Regards,
    Alec

  • 0 in reply to Alec May
    TI__Genius 17265 points

    Alex,

    After doing some digging, something I found is that if the channel map update indicates that it should take effect on the next connection event, then the peripheral device will wake up at the immediate connection event in order to meet that condition. I believe this is what is happening in this situation. 

    Best Regards,
    Alec

  • 0 in reply to Alec May
    Intellectual 420 points

    Hi Alec,

    thanks for looking into this further. However I'm not convinced the scenario you described applies here. Looking at the trace I provided above, the instant field of the channel map updates is in most cases set to a connection event further into the future. The peripheral then seems to activate on these as well (or the ones directly before), which at least explains some other instances where the peripheral seemed to cut the slave latency a little short.

    I have also been poking around the specification and I think Section 5.5.1 of Core 5.2, Vol 6, Part B presents an explanation that could better match the immediate reactivation. Certain procedures with istant fields apparently require sort of a three-way handshake. Since the peripheral sends last in a connection event, additional connection events are needed to observe whether the central received the acknowledgement. Can you confirm if that section applies here?

    Sincerely,

    Alex

  • 0 in reply to Alexander Wenner
    TI__Genius 17265 points

    Hi Alex,

    Okay so I think i've got my head fully wrapped around this now. So for starters, we do not officially support BLE version 5.2 yet, so you will want to refer to the core spec version 5.1 Section 5.5 Vol 6 Part B, but after conferring with some of my colleagues we have come to an agreement that we do in fact believe that is the root cause of your problem. Specifically, the 3rd paragraph of section 5.5 addresses what we are seeing. Instants are one of the more complex subjects in the spec so my apologies for not recognizing this earlier. Let me know if you have any further questions.

    Best Regards,
    Alec

  • 0 in reply to Alec May
    Intellectual 420 points

    Hi Alec,

    thank you for the confirmation. Unfortunately for me that means everything behaves as expected and there is no room for improvements. Thanks again.

    Sincerely,

    Alex