• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 52 subscribers
  • Views 403 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2640R2F-Q1: Connection timing BLE central with multiple peripherals

Finn Schmitz
Prodigy 25 points
Part Number: CC2640R2F-Q1

Hallo all,

we are currently evaluating the usability of the CC2640R2F-Q1 BLE SoC for our purposes. To assess this, I would ask you to clear up the following points, which are not clear to me at the current time.

Assume that the CC2640R2F-Q1 is used as a central and scanning for advertisement packages from a/multiple peripheral(s) with a slow advertisement interval (let’s say 5s). How does the BLE stack behave in the following circumstances?

- Will it switch from scanning to connection and initiate a connection with the first advertisement package received? Or will it switch to connection mode on the first package and then send the connection request on the second advertisement package, 5 seconds later? The overall question is, will the connection request be sent some milliseconds, or 5 s after the first advertisement package scanned?


- If the answer to the first point is, that it takes 5 seconds. Will the BLE stack then wait in connection mode for 5 seconds and not perform any scanning in the meantime? Or will it in parallel scan for other devices, so that connection request can be started in rapid succession afterwards (assuming that we already know the advertisement interval of the peripheral, which is true in our use case)? This has a huge impact, since it will make the difference between the connection to N peripherals will take 5*N seconds, or just “a bit more” than 5 seconds.

Thank you very much for your support!

Kind regards
Finn

  • 0
    TI__Guru* 78891 points

    Hi Finn,

    If you send a connection initiation command (GapInit_connect ()) the next advertisement packet will be met with a connection request. However in order to connect to a device you need their address. So if you don't know the peer device address, you would normally scan their packet first to learn their address.

    For the second question we will have to get back to you.

  • 0 in reply to Marie H
    Prodigy 25 points

    Hallo Marie,

    thank you very much. That is very much appriciated!

    Kind regards

    Finn

  • 0 in reply to Finn Schmitz
    TI__Intellectual 1670 points

    Hi Finn,

    As Marie said, you will need the peer device address for the connection request. This means that the scan of the first advertisement will resolve the address, and the connection request will happen (earliest, if scan is stopped) on the second interval. If the the peer device advertisement interval is 5s, the connection request will happen 5s after the first advertisement if the connection is initiated just after a peer device is scanned.

    One thing to be aware of, that will partially answer your question, is that you can resolve information from multiple peer devices during one scan. This means that after one scan, you are ready to initiate connections to all your peer devices (one by one). If you are in control of all the peripherals, and they all have 5s advertisement intervals, a scan window of 5+ seconds will be sufficient to receive advertisements from all peripherals.

    The connection initiation is directed to a specific peer device (address), and the central will stay in this mode waiting for an advertisement from the specific address until the peer device replies (or the attempt to connect is terminated by the central). After the second peripheral advertisement, the connection request will contain a (small) time offset for the next (first connection) event were the central and peripheral get linked.  

    The worst case time it will take for connecting to N peripherals will be N * "advertisement interval" in your case. This is due to the worst case of initiating a connection to a peripheral just after an advertisement, which means that the central will have to wait for the next advertisement to send the connection request.

    Best regards,

    Vetle