This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

128-bit UUID byte swap problem

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: image description

Parents
  • There's nothing wrong with that, the bytes are little-endian and the number is displayed in the MCP as a big-endian number.

    You say all the octets between those are fine ... well all the octets between those are all 0x00 so you wouldn't be able to tell which order they were in.

    Why are they all zero by the way, it's probably a legal UUID but certainly not one you randomly generated.

  • I really don't understand your question. There is no problem. You have entered a series of bytes in an array to use for your UUID. Those bytes represent a 128 bit number. The first byte in the array is the least significant byte, the 16th is the most significant byte. When you look at the number formatted for humans to look at, which is most-significant byte first, you see the last byte in the array going all the way down to the first byte in the array.

    This is not 'the first and last pairs of bytes are swapped and they are also swapped within the pair'. This is 'I see the number with the bytes displayed in the exact opposite order to the way they are in the array, with the 16th first, then the 15th, then the 14th all the way down to the first'.

Reply
  • I really don't understand your question. There is no problem. You have entered a series of bytes in an array to use for your UUID. Those bytes represent a 128 bit number. The first byte in the array is the least significant byte, the 16th is the most significant byte. When you look at the number formatted for humans to look at, which is most-significant byte first, you see the last byte in the array going all the way down to the first byte in the array.

    This is not 'the first and last pairs of bytes are swapped and they are also swapped within the pair'. This is 'I see the number with the bytes displayed in the exact opposite order to the way they are in the array, with the 16th first, then the 15th, then the 14th all the way down to the first'.

Children
No Data
Related