BUG: nRF Connect changes/breaks 128bit UUIDs

[ChrisRW]

Hi there!

I'm trying to simulate a peripheral with a PCA10040 and nRF Connect for Desktop.

I've made the Server Setup, applied to the board and started advertising - everything seems fine.

I created a "custom base-uuid" for my services and charactersitics.

Here is a screenshot of my server config while advertising:

But when I connect to the dongle and do a discovery, I get different/broken UUIDs. Actually, every first characteristic in a service is OK, but the other ones are broken.

Strange thing also: the UUID in Handle 0x0017 should be in the other Service @Handle 0x000C! (F004F000... instead F005F000...)

Both my BLE-Analyzer (Cypress CySmart) and the nRF Connect on Android show the same discovery results...

I hope this gets fixed soon =) as I rely on nRF Connect for now.

Best regards,

Chris

[Edvin]

Hello Chris,

What have you programmed the nRF52 with? Did you use the nRF5 SDK, or NCS (zephyr)?

To me, all this looks a bit strange, because this is typically not where you insert the characteristic specific UUID. Usually it is byte 3 and 4 that are characteristic specific, and not byte 2.

If you used the nRF5 SDK, what verison did you use? Does it happen on all the examples? Or only your custom application? If it is only the custom application, can you show me how you implemented the service? Perhaps I can reproduce it?

If you used NCS (Zephyr), can you show me how you set up your service there?

BR,

Edvin

[ChrisRW]

Hi Edvin,

I'm using just a PCA10040 together with the app "Bluetooth Low Energy" from within nRF Connect v3.3.3.

So actually no single line of code or usage of the SDK.

It is quite easy to reproduce:

In the Server Setup Tab you just have to add a two new services and two characteristics; all with 128bit UUIDs.

Example:

• service 0: F000F000AAAAAAAAAAAAAAAAAAAAAAAA
• service 1: F001F000AAAAAAAAAAAAAAAAAAAAAAAA
  • characteristic 1.1: F001F001AAAAAAAAAAAAAAAAAAAAAAAA
  • characteristic 1.2: F001F002AAAAAAAAAAAAAAAAAAAAAAAA
• service 2: F002F000AAAAAAAAAAAAAAAAAAAAAAAA
  • characteristic 2.1: F002F001AAAAAAAAAAAAAAAAAAAAAAAA
  • characteristic 2.2: F002F001AAAAAAAAAAAAAAAAAAAAAAAA

Then you can just start advertising, connect to it (i.e. with nRF Connect on Android) and check the discovered UUIDs.

You should get a broken UUID for characteristic 1.2 and instead of the characteristic 2.2 there is 1.2.

If you then change 1.2 to lets say F011F002... it will be again at 2.2, but 1.2 is OK.

Putting service 0 at the end seems to fix all.....very strange.

I hope you can reproduce it this way.

BR,

Chris

[Edvin]

Oh, I see what you mean now. I was not aware that you set up the peripheral in nRF Connect. I don't think this is commonly used, but I will forward it to our nRF Connect tools team. Thank you for reporting.

If you want to develop an actual product, I suggest you look into our SDK. In the meantime, this will hopefully be fixed for a future release of nRF Connect for Desktop.

BR,
Edvin

[ChrisRW]

Well, I am developing an actual product - the central device.

I use nRF Connenct to verify and debug my central, because it is really great for that use!

At least I found a workaround for the meantime.

BR,

Chris