This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Scan Response T_IFS Violation

My bluetooth analyzer is showing that my peripheral's scan response packets have a T_IFS Violation 326.125 us too long. I don't use scan response data for anything but I want to understand why I am seeing this and if I can fix it.

Name Value

Link-Layer Information
Sniffer Radio
RX Strength (RSSI) -40.0 dBm
RX Quality High
RF Gain 6.0 dB
RF Channel
RF Channel Frequency 2402 Mhz
RF Channel Number 0
RF Channel Index 37 (adv)
Initial Center Frequency Offset -7.81 kHz
Link Layer
PHY LE 1M
Coding Scheme Uncoded (1 Mbps)
Access Address 0x8E89BED6
Received Access Address 0x8E89BED6
CRC Initial Seed 0x555555
Physical Channel Advertisement ("SON:82CE" F5:92:E4:62:F1:13 (Static))
Timing
Start Time 2,390.597 964 000
Duration 128 us
Delta from Previous 814.13 us (1.3 slots)
T_IFS 478.125 us
T_IFS Violation 326.125 us too long
Devices
Originator Master
Transmitter Master: "SON:82CE" F5:92:E4:62:F1:13 (Static)
Receiver Slave: "Scanning Device"
Master Address F5:92:E4:62:F1:13 (Static)
Slave Address Unknown BD_ADDR
Link-Layer Packet
Header
PDU Type SCAN_RSP
RFU Reserved (0)
RFU (ChSel) Reserved (0)
TxAdd Random
RFU (RxAdd) Reserved (0)
Payload Length 6
Advertiser Address F5:92:E4:62:F1:13 (Static)
Scan Response Data
Non-significant Part 0 bytes
CRC Valid
Raw Content
Raw Data 44 06 13 F1 62 E4 92 F5 03 F8 3E
Whitened Raw Data C9 D4 44 50 5F 43 F4 45 76 C9 2F

Parents Reply Children
  • The peripheral is a custom board. The sniffer is an Ellisys Bluetooth Tracker. The trace I provided was just normal traffic going on. I see lots of these timing warnings but only on the SCAN_RESP packets. Once I am connected the connection seems to be very stable but I do fail ~2% of my connection requests. I just get a BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED error that it failed to connect. Since the connection is stable once connected do you think this is not a clock issue? If so then what should I check next?

  • Which softdevice do you have on the board ? 
    Do you see the timing warnings on all of the SCAN_RESP or only on some ? Could you provide a trace? 

    I don't think it's a clock drifting issue because it's way too much for a drift. And with that 300% tolerant, it won't be able to keep any connection. 

  • I am using s140_nrf52_6.1.0_softdevice.hex with SDK 15.2. We tested the clock and it is within spec of 20ppm. I don't always see the error, just occasionally. I can provide an ellisys trace, you can open it using the Ellisys bluetooth analyzer software. phy update.btt

  • Hi Matthew, 

    I had a look at the sniffer trace but in all the places that I can find "T_IFS Violation ", I couldn't find the scan request packet in the trace. 

    You can see in this screenshot: 

    On a normal scan request-scan response scheme, the distance from the advertising packet to the scan response packet is 813us, matching perfectly with the time delta of the scan response that has the T_IFS violation = 813us. 

    This suggest that it could just be the issue of that the sniffer simply missed a scan request packet. 

    If you find other place that the distance between the scan request and scan response is >150us , please let me know. 

Related