RE: Beacon Scan response request and packet timing

MartinBL — Wed, 24 Jan 2018 16:04:03 GMT

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.