This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Packet sniffer shows that TI's BLE stack doesn't follow BT 4.0 spec

Here's a snapshot of packet sniffer capture from TI's wiki:

    http://processors.wiki.ti.com/index.php/File:Using_capt_adv.png

If you look at the "Adv PDU header" field of the first captured packet, you will notice that the PDU length is 17. In "Packet details" tag, it shows the raw "Adv PDU header" message is "0 0 1 1" hex. At first look, it seems correct because 0x11 is 17. However, if you take a look at the BT 4.0 spec Volume 6.B.2.3 (page 2202), you will notice the advertising channel PDU header has the following format:

    LSB ............................................................ MSB

    PDU Type | RFU  | TxAdd | RxAdd | Length | RFU

        4 bits     | 2 bits | 1 bit    | 1 bit     |  6 bits   | 2 bits

The 2 MSBs are reserved bits and shouldn't be used as part of the PDU length. To to have a PDU length as 17 bits, the correct advertising PDU header raw message should be (using the above example): 0x0044, instead of 0x0011.

Did I misinterpret the BT spec or TI?

I upgraded my sensortag firmware. My sniffer capture shows similar result as shown in the TI wiki.

  • Hello,

    If you read the following section you see that the 2 bits reserved for future use (RFU) is the most significant bits in the octet (byte) and therefor 0x11 is correct.

    1.2 BIT ORDERING
    The bit ordering when defining fields within the packet or Protocol Data Unit (PDU) in the Link Layer specification follows the Little Endian format. The following rules apply:
    • The Least Significant Bit (LSB) corresponds to b_0
    • The LSB is the first bit sent over the air

  • You misinterpret the spec. As you can see above, the LSB is written to the left (as transmission is LSB first). The RFU bits are in the MSB of the header. With PDU type = 0, RxAdd = 0, RxAdd = 0 and Length = 17, you get the 16-bit header 0x1100, or in transmission order, the two bytes 0x00 0x11.

  • Yes, it's my fault. Thank you all for the quick answers.

  • How about the CRC field? According to spec:

    Multi-octet fields, with the exception of the Cyclic Redundancy Check (CRC)
    and the Message Integrity Check (MIC), shall be transmitted with the least significant
    octet first. Each octet within multi-octet fields, with the exception of the
    CRC (see Section 3.1.1), shall be transmitted in LSB first order.

    When packet sniffer interprets the CRC field, why the byte order is not the same as the received raw CRC bytes?