Texas Instruments SimpleLink CC2620 Technical Reference Manual page 1568

Bluetooth Low Energy
If the packet being received did not fit in the RX queue, the packet is received to the end, but the received
bytes are not stored. If the packet would normally not have been discarded from the RX buffer, the
operation ends.
If the action from the received packet is
procedure. This procedure starts with decrementing pParams ->backoffCount. If this variable is 0 after the
decrement, a SCAN_REQ is transmitted. If not, the operation ends. If the action from the received packet
is number 2 or number
This is configured with pParams ->scanConfig.bEndOnRpt; if 1, the operation ends, otherwise scanning
continues.
When transmitting a SCAN_REQ, the radio CPU constructs this packet. In the header, the PDU Type bits
are 0011b. The TXAdd bit is as shown in pParams ->scanConfig.deviceAddrType. The RXAdd bit is as
shown in the TXAdd field of the header of the received ADV_IND or ADV_SCAN_IND message. The
length is calculated from the size of the scan request data, pParams->scanReqLen + 12. The RFU bits are
0. The payload starts with the 6-byte device address, which are read from pParams ->pDeviceAddress,
followed by the 6-byte peer address read from the AdvA field of the received message. By the BLE
specification, there is no more payload, but a noncompliant message may be constructed by setting
pParams->scanReqLen to a nonzero value. If so, the rest of the payload is read from the
pParams->pScanData buffer.
After a SCAN_REQ message is transmitted, the radio CPU configures the receiver and looks for a
SCAN_RSP from the advertiser to which the SCAN_REQ was sent. If sync is obtained on the
demodulator, the header is checked once it is received, and if it is not a SCAN_RSP message, the
demodulator is stopped immediately. If it is a SCAN_RSP message, then it is received into the RX queue.
Depending on the received SCAN_RSP, the values of bCrcErr and bIgnore are as given in
If pParams->scanConfig.bStrictLenFilter is 1, only length fields that are compliant with the BLE
specification are considered valid. For a SCAN_RSP, valid means a length field in the range 6–37. If
pParams->scanConfig.bStrictLenFilter is 0, all received packets with a length field less than or equal to the
maximum length of an advertiser packet (37, but can be overridden) are considered valid. If the length is
not valid, the receiver is stopped.
Table 23-124. Actions on Packets Received by Scanner After Transmission of SCAN_REQ
PDU Type
SCAN_RSP
SCAN_RSP
SCAN_RSP
SCAN_RSP with
invalid length
Other
No packet received
After receiving or trying to receive a SCAN_RSP, the backoff parameters are updated by the radio CPU.
The update depends on the result as given in the SCAN_RSP Result column of
values of the backoff parameters. The backoff parameters given in pParams->backoffPar are updated as
shown in Table 23-125. After this update, the radio CPU sets pParams->backoffCount to a pseudo-
random number between 1 and 2
Old pParams->backoffPar
SCAN_RSP
Result
bLastSucceeded
Failure X
Failure 0
Success 0
Success 1
1568
Radio
number
3, the next action may either be to continue scanning, or to end the operation.
AdvA Same as in
CRC Result
Request
OK No
OK Yes
NOK X
X X
X N/A
N/A N/A
pParams->backoffPar.logUpperLimit
Table 23-125. Update of Backoff Parameters
bLastFailed
0
1
X
0
Copyright © 2015, Texas Instruments Incorporated
3, a SCAN_REQ is transmitted if allowed after a backoff
bCrcErr bIgnore
0 1
0 0
1 0
– –
– –
– –
.
New pParams >backoffPar
bLastSucceeded bLastFailed
0 1
0 0
1 0
0 0
SWCU117C – February 2015 – Revised September 2015
www.ti.com
Table 23-124.
SCAN_RSP Result
Failure
Success
Failure
Failure
Failure
Failure
Table 23-124 and the old
logUpperLimit
logUpperLimit
min(logUpperLimit+1, 8)
logUpperLimit
max(logUpperLimit-1, 0)
Submit Documentation Feedback