128-bit UUID byte swap problem

RE: 128-bit UUID byte swap problem

RK — Mon, 01 Jun 2015 13:33:28 GMT

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.

RE: 128-bit UUID byte swap problem

kerem — Mon, 01 Jun 2015 13:26:22 GMT

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.

RE: 128-bit UUID byte swap problem

Hung Bui — Mon, 01 Jun 2015 08:50:20 GMT

@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 ?

RE: 128-bit UUID byte swap problem

RK — Thu, 28 May 2015 23:09:30 GMT

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'.

RE: 128-bit UUID byte swap problem

kerem — Thu, 28 May 2015 16:32:37 GMT

I deliberately set them to 0x00 for brevity. At first sight i was able to observe the order problem in the first 2 and last 2 bytes since i manually entered them. So is this ok or should i encode the uuid first to change its endianness?

RE: 128-bit UUID byte swap problem

RK — Thu, 28 May 2015 15:06:53 GMT

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.

RE: 128-bit UUID byte swap problem

kerem — Thu, 28 May 2015 13:49:37 GMT

I haven't tried any other example but I lookup up other questions here and implemented as seen here setting up the base first and using returned uuid_type from the function sd_ble_uuid_vs_add. I attached a screenshot of what I see on MCP application. Edited my post as this is related to softdevice 7.0.0 and SDK 6.1.0 on nrf51-DK, I'm doing this using Keil 5.0 running inside VirtualBox on OS X.

RE: 128-bit UUID byte swap problem

Hung Bui — Thu, 28 May 2015 13:32:39 GMT

@Kerem: What you described is pretty strange. Could you provide a screenshot of what you experienced ? Where did you read the UUID that have swapped bytes ?

Have you tried our example ble_app_uart in \Board\pca10001\s110\experimental folder ? I that example we also declare 128bit UUID service. I don't see the swapping issue when testing with this example and the Master Control panel.