• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 252 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.

CC2652R: Param update/handshake between peripheral and central cache issue

Matt Gaidica1
Expert 1540 points

Part Number: CC2652R

I'm experiencing strange behavior related to param updates. Below are my peripheral settings. When my central establishes a connection to peripheral, it waits for params to be updated before performing some data exchange, because I need to guarantee low latency. What is strange is that I flashed the exact same device with the same software (and same randomAddress), but the second device will never have its params updated. Even after all devices are reset. If I increment the randomAddress, the params update as expected. To me this sounds like some sort of cache that is being held in central ROM, perhaps telling it that it doesn't need to send the param update or something, but I'm a bit stuck and incrementing the randomAddress seems like a major hack. Thanks for any insight,

  • 0
    TI__Guru** 101540 points

    Hi Matt, 

    This sounds like an issue at the application level. I would recommend to do the following:

    • using a protocol analyzer (BLE sniffer) assess if the connection update is properly sent. If not possible, you can check using some breakpoints if the device sends the connection update request. 
    • verify if the behavior reproduces if the devices are not bonded. 
    • consider forming the connection directly with the low latency connection parameters 

    I hope this will help, 

    Best regards,

  • 0 in reply to Clément
    Expert 1540 points

    I'm convinced there is still some form of 'offline' or non-volatile caching here, it doesn't make sense that changing the address on my peripheral alters the behavior on central after full power cycles. I ended up establishing low-latency parameters and this seems to play nice with my iOS central app, which I assume is requesting a connection interval of ~30ms instead of the 7.5ms that I have as default (and need for the low-latency, TI-based central device).

    To that end, I'm quite happy with the consistency of the 7.5ms connection interval as tested from peripheral to central on my oscilloscope. As far as I know, there is no simple way to know what that latency truly is, so in a closed-loop system, I just have to assume it is 7.5ms and include that as a 'line delay', which has been robust even in 2.4GHz congested environments.