• State Suggested Answer
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 62 subscribers
  • Views 6033 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 129707
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Beacon Scan response request and packet timing

NorBLE

I'm reading about beacon scan response requests and scan response packets, where a client (like a phone) can request the beacon respond back with local name and other info. I have a few questions regarding this:

  1. After a Beacon sends its advertisement, when does it start listening for the scan response request? Does it go to sleep for like 150mS because BLE specifies that clients only send the response after 150mS so there's no point in listening before then? I see a reference to this timing, but I don't know if this is a spec or if the reference was an example.

  2. Is the scan response mechanism between beacon and client available for any type of BLE advertisement? ADV_SCAN_IDN obviously, but can ADV_NONCONN_IND also use the response mechanism? That is, if you have an observer that's a nordic BLE module, can you chose to send scan response requests to ADV_NONCONN_IND beacons, or does the stack filter it out so you can only send those requests to ADV_SCAN_IDN?

  3. Similar question as #2, but for the beacon. If you're a Nordic beacon advertising, how do you tell it to listen to scan response requests? Is it an automatic result of advertising as ADV_SCAN_IDN? Or can you listen for response requests even if you're setup to advertise as ADV_NONCONN_IND?

  • 0

    Hi,

    1. The beacon starts listening for scan request almost immediately after it has transmitted its advertising packet. Please refer to the BLE Specification Version 5.0 | Vol 6, Part B, CH 4.4.2.5.1 "Scannable Undirected Event Type using ADV_SCAN_IND". There you will find the following figure:

    tifs

    The adv packet, scan request, and scan response is separated by a time length called T_IFS. The T_IFS (Time Inter Frame Space) is defined in the spec to 150us (see spec Vol 6, Part B, Ch 4.1.1 "Inter Frame Space").

    Here is a plot of the nRF52's current consumption when it is advertising and receiving scan requests:

    image

    You can clearly see the current visualizes how the radio sends packets on all three advertising channels, listens for scan and connect requests, and sends scan responses. You can also see the inter frame space. The Softdevice handles all this for your, but does not have the time to put the CPU to sleep between each radio operation (as indicated by the 4mA current draw between the radio frames).

    1. Please refer to Spec Version 5.0 | Vol 6, Part B, Ch 4.4.2.6 "Non-Connectable and Non-Scannable Undirected Event Type":

    The non-connectable and non-scannable undirected event type allows a scanner to receive information from the advertiser. This information is contained either in the ADV_NONCONN_IND PDU or in an AUX_ADV_IND PDU pointed to by the AuxPtr field of the ADV_EXT_IND PDU.

    The advertiser shall either move to the next used primary advertising channel index or close the advertising event after each ADV_NONCONN_IND or ADV_EXT_IND PDU that is sent. The Link Layer does not listen, and therefore cannot receive any requests from scanners or initiators

    In other words, a non-connectable or non-scannable device will not receive scan requests and/or transmit scan responses.

    1. All this is handled by the stack according to the BLE spec.
Related

core_v2_widget.Hide()