• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 51 subscribers
  • Views 413 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.

Long time until connection is established

Dominic Kuschmierz
Prodigy 170 points
Part Number: CC2640R2F
Other Parts Discussed in Thread: CC2650,

Hi,

currently i'm trying to connect to a device running a CC2640R2F with an SmartRF06 EVB running a CC2650EM-7ID. The CC2650 is controlled via BTool in standard setting. The CC2640R2F has an advertising intervall of 3s.

My problem is, that sometimes the time until the connection is established takes ~3s and sometimes it takes >50s.

I sniffed the communication between both devices and there i saw, that even the establishment request is not send until after 50s.

So i assume that there are some timing settings not correct in BTool for the advertising intervall of the CC2640R2F (something like TGAP_CONN_SCAN_INT), and the BTool doesn't see the device earlier...

Which parameter should it be? What else can be wrong?

Here is the sniffed log:

Immediately after the scan response (number 1157) i pressed the establish button in BTool and then it takes ~50s until the CONNECT_REQ is sent.

  • 0
    TI__Mastermind 33460 points
    Hi Dominic,

    When establishing a connection, the stack will first perform a scan of all devices around, looking only for the device you are trying to connect to.
    These scan parameters are controlled via TGAP_CONN_EST_SCAN_INT and TGAP_CONN_EST_SCAN_WIND. They can set in BTool under the advanced commands. It is important to match these parameters with the advertising interval of the advertiser device.

    Tweaking these might show quicker connection establishment times.
  • 0 in reply to Sean2
    Prodigy 170 points

    Hi,

    unfortunately this did not help. For my understanding, is it right the window and interval correspond like in the following picture? If yes, this feature is only to save power, or? If I set both values to the same value, i should have continuous scanning. With the standard-value of 10ms, I definitely should see a device advertising every 3 seconds then...

    What resolved my problem, was enabling the highDutyCycle flag in Establish Link request command. Can anybody explain me, what this flag exactly does?

  • 0 in reply to Dominic Kuschmierz
    TI__Mastermind 33460 points
    Hello,

    The picture you have attached is reversed. From the Bluetooth Core Spec version 5.0, Vol , Part B, Section 4.4.3
    "During scanning, the Link Layer listens on a primary advertising channel index
    for the duration of the scan window, scanWindow. The scan interval,
    scanInterval, is defined as the interval between the start of two consecutive
    scan windows."

    The interval is the time between the consecutive scans the window is the measure of how long the device is listening during the interval.
    If you want to guarantee seeing the device that is advertising at 3s, you would need at least a 3s window. This may be unfeasible depending on the scheduling constraints of your application.

    Overall, increasing the scan duty cycle is a better way to detect the device earlier.
  • 0 in reply to Sean2
    Prodigy 170 points

    Hi Sean,

    thank you for the clarification on Window/Interval.

    Is it really necessary to increase the timings to 3s? As you can see on the sniffed log, the device advertises on all 3 adv. channels within 8ms. My assumption was, that a scanning interval and window of 10ms must definitely see the the device, because 3s is dividable through 10ms and I have no time in-between where I'm not scanning. I always thought, that these parameters are to save energy on the central side. E.g. to set a window of 1s and the interval to 10s. But setting the values equal should lead to continuous scanning, or?

    Can you please explain what the scan duty cycle flag exactly does?

    Best regards

    Dominic

  • 0 in reply to Dominic Kuschmierz
    TI__Mastermind 33460 points

    Hi Dominic,

    Is it really necessary to increase the timings to 3s?
    Not exactly but you run the risk of not scanning while the other device is advertising. If you miss the advertising events (at a 3s interval) then you will not detect the other device. Scanning for more than 3s is a guaranteed way to detect the other device, but any increase in the window and overall duty cycle will increase the likelihood of detecting the device.

    Can you please explain what the scan duty cycle flag exactly does?

    The duty cycle is the measurement of how often the device spends scanning in a given interval. If WIND and INT are equal then you are doing continuous scanning.

    A higher duty cycle increases the likelihood of finding your device in fewer scans, of course this has an associated power tradeoff.