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.

CC2650 SimpleBLEobserver BLE address stored with LSB first in gapDevRec_t.addr

The BT Core Spec defines clearly, that higher significant data are send out first. The Smart Packet Sniffer shows the device address in correct sequence.

Why is the BT address then stored in gapDevRec_t.addr with the LSB at addr[0] ?

Interesting is that  in the SimpleBLEobserver project the display function shows the address in correct order by turning the direction.

Thank you

  • Hi Ralph,

    Can you point me to the spec? Maybe I'm wrong, but I thought LSB should come first in BLE.

    - Cetri
  • Hi Cetri,

    first to clarify I ment Byte when I say LSB/MSB, so I should have used BT notation LSO and MSO for octet.

    If you refer to BLUETOOTH SPECIFICATION Version 4.1 [Vol 2] 1.2 at page 69 you find this:

    The address shall be created in accordance with section 9.2
    ("48-bit universal LAN MAC addresses") of the IEEE 802-2001 standard (http://
    standards.ieee.org/getieee802/download/802-2001.pdf)


    and further down this

    All addresses have the LSB at the rightmost position, hexadecimal
    notation.

    if you refer to IEEE 802-2001 at page 20 you find this

    The standard representation of a 48-bit LAN MAC address is as a string of six octets, using the hexadecimal representation (3.1.8).

    refering to page 5 with this

    3.13.1.8 hexadecimal representation:

    The representation of a sequence of octet values in which the values of

    the individual octets are displayed in order from left to right, with each octet value represented as a two-digit

    hexadecimal numeral, and with the resulting pairs of hexadecimal digits separated by hyphens. The order of

    the hexadecimal digits in each pair, and the mapping between the hexadecimal digits and the bits of the octet

    value, are derived by interpreting the bits of the octet value as a binary numeral using the normal mathematical rules for digit significance

    according to this the BD_ADDR is stored in gapDevRec_t.addr in reverse sequence.

    The packet sniffer shows the ADDR in the right natural 48bit HEX representation.

    So I think I am right.


    Thank you