Is BLE data sends in LSB first and Little Endian byte order?

[Muniek]

Hi,
I'm confused, according to Bluetooth 4.0 Specification bytes are send in Little Endian byte order, and with LSB first in every byte.
So when I receive raw data from characteristic in nRF52 device, I need to change bytes order from Little to Big Endain and reverse bits in every byte to receive "human readable" raw data but thats not true.
Data I received is in "human readable" order already.
where did I make a mistake?

Thanks :)

[Vidar Berg]

You may need to account for the endianness when you use data types that consist of more than one byte. E.g., if you try sending an int value, you will see that the hex values are arranged in little-endian format. The "human readable" value 0xAABBCCDD will for instance be transmitted and received as 0xDDCCBBAA.

[Muniek]

Thanks for your replay:)
What about larger values, eg. AABBCCDD11223344, why it is received like:
DDCCBBAA44332211 instead of just reveresed 44332211DDCCBBAA like in your example?

[Vidar Berg]

It depends on the size of the data type you use. It would have been 44332211DDCCBBAA if it was 64-bit long

[Muniek]

ohhh thats make a lot of sense now! Thank you! :)

But what about "6.2 BIT ORDERING" in Bluetooth 4.0 Specification:
"The least significant bit (LSB) corresponds to b0 -- b0b1b2 = 110"

So, it looks like I have to reverse bits in every byte, eg. If i receive 0xA which is 0b00001010, then to make it "human readable", I need to reverse it to 0b01010000 which is 0x50 but it is not the case here.
Thanks :)

[Vidar Berg]

This does not apply for data packets; they are in little-endian byte order.

[Muniek]

Cannot be both? If something is little-endian byte order, cannot it be LSB (bit) first also?
Chapter 6 in specification refers to packets, and 6.1 about packet bit ordering:
"The least significant bit (LSB) corresponds to"
Sorry if it is stupid question but thats what wonders me

[Vidar Berg]

I understand the confusion. Chapter 6 in volume 2 is for the BR/EDR controller while the low energy controller specification is covered by Vol. 6. I think you would be more interested in reading the GATT profile specification in volume 3, Part G. It states the following about endianess:

"Multi-octet fields within the GATT Profile shall be sent least significant octet
first (little endian)."

You are right in that there are some fields that must be arranged in little-endian bit order (packet headers for instance), but that's taken care of by the Softdevice. Also, as you may know, the nRF5 ICs are configured with little-endian memory systems which mean that data is already arranged in the little-endian byte format (this is a common configuration for CPUs). 

[Muniek]

Thank you very much!, now it makes sense :)

[Vidar Berg]

Glad to hear that it made sense:) Please accept one of the answers to close this thread.