Beacon Scan response request and packet timing

Question

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: 
 
 
 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. 
 
 
 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? 
 
 
 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?

MartinBL · Answer

Hi, 
 
 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: 
 
 
 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: 
 
 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). 
 
 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. 
 
 All this is handled by the stack according to the BLE spec.

Beacon Scan response request and packet timing

Top Replies