Why big-endian for Eddystone Configuration GATT Service?

[beaufortfrancois]

I've been asked this question and I'm not sure why big-endian was chosen there.

[roywant]

The reason is consistency with what was already happening in the beacon community. Other major players, before Google's Eddsystone release, had already chosen to use big endian parameters (e.g. IDs) in their beacon ADV packets. Google's Eddsystone ADV packets followed suit in its July 2015 release. Now in April 2016 Google released its EID beacon format and the Eddystone GATT Configuration Service, also in big endian format for consistency.

[Vudentz]

For the record both GATT and ADV headers are in fact encoded in little endian, so it is not consistent in any way.

[mashbridge]

The BLE elements -- UUID and such -- are little-endian of course. Roy was referring to the "user data", if that's not an overly broad term. Other players used network byte order for their service data and/or manufacturer data elements, so we tried to be consistent with that. It's an arbitrary choice to be sure, but it's a choice that was made. On many systems writing and reading the values is less work (sorry iOS), but if you're working down at this level we don't expect swapping bytes to pose much of a challenge. Please do say if there's anywhere in the documentation where it's not clear how something is supposed to be read/written.

[Vudentz]

Looks like it is not conforming to the CSS in case of advertising packets: https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=291904

Supplement to Bluetooth Core Specification page 9 of 37:
"All numerical multi-byte entities and values associated with the following data
types shall use little-endian byte order."