128-bit UUID byte swap problem

[kerem]

I'm implementing a custom service with one characteristic and 128-bit UUID.

I am able to set the custom base UUID using sd_ble_uuid_vs_add() but the resulting bytes look swapped in nRF MCP Android application. This is on Softdevice 7.0.0 and SDK 6.1.0.

#define BASE_UUID {0xAB, 0xCD, .., 0x12, 0x34}

the resulting UUID I see is first and last 2 octets swapped, also within themselves like this;

{0x34, 0x12, .., 0xCD, 0xAB}

All the octets in between these 4 are fine.

Any idea what could cause this behavior?

EDIT Attaching screenshot from Android MCP:

[Hung Bui]

@kerem: What RK explained was correct. It was the encoding difference. In the code we use little endian but when displaying on MCP it was big endian. Could you try smth else not with 00 in the middle ?

[kerem]

I understand the reason is the reverse endianness between nrf51-dk and MCU Android app, fine. What i dont understand is why? I dont remember anything about this even though i used MCP quite a lot so far for displaying various diffrent UUIDs. It feels strange that i never noticed such behavior.

[RK]

It's just a corollory of the BTLE spec. Each parameter is transferred little-endian and the way it's specified in the code is in the order the data is going to be transmitted, so least significant byte first. That saves I suppose, the softdevice having to flip it all around before storing it/sending it. The conventional way for humans to look at UUIDs however is big-endian in groups with dashes.

It's quite easy to look at UUIDs in the MCP or other place they're displayed and not even think about the order they were specified in code originally, seems that this particular time you did look closely and saw it, but it will have been that way forever.