Integers in characteristics little or big endian?

This is a simple question: If I have a characteristic with, let's say an int16_t in it and catch the write event in a ble_gatts_evt_write_t structure - is the data field in little or big endian order?

I tried writing to my characteristic with Nordic's Master Control Panel app on iOS and either the app writes it in big endian order or the data array is reversed in the Nordic SDK.

Is that a bug in the MCP app or is the big endian order intentional here in the Nordic SDK?

Generally, Bluetooth GATT seems to use little endian for all characteristics.

  • Hi

    I'm not entirely sure if I got all this right, but:

    The Bluetooth Core spec Vol 3: Part A, Ch. 3, "Data Packet Format" says:

    All L2CAP layer packet fields shall use Little Endian byte order with the exception of the information payload field. The endian-ness of higher layer protocols encapsulated within L2CAP information payload is protocol-specific.

    So the payload is received and stored in memory as big endian. If I use MCP (on my PC) and write 0x11223344 this is how it is transmitted and how it is stored in memory:

    image description

    However, the nRF5 core is little endian so if I cast the four byte long data into an uint32_t I will get 0x44332211.

Reply Children
No Data