Integers in characteristics little or big endian?

[Raphael]

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.

[MartinBL]

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:

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

[Raphael]

OK, It may be true that it is generally up to the higher layers, but any Bluetooth GATT service, such as the Heart Rate Service. They all use Little Endian. So Nordic's MCP really should not set integers in Big Endian order since it's largely inconsistent with GATT's standard services.