Discovering a VS UUID Characterisic, but it shows UUID as 0

[Dresse]

Hi,

I am running SDK15, and using the example ble_app_interactive in ble_central and peripheral. I am trying to discover services and characteristic from a peripheral device, using NRF52 DK as a central device. There is a lot of services and VS services and characteristic in the peripheral. I can discover the services, and see the VS UUID services. As seen on picture:

But when i try to discover the characteristics in the VS services, it writes out the UUID as 0. I have also made it print out it handles and it does have it's handles Both things is shown in pictures below.

The UUID is 0. This is by using gatt characteristics <address> 2EAF.

If i then try to write gatt characteristics <address> AE62. I still don't get UUID, but my progam also crashes and gives me error code 11, but this is in the CCCD descriptor, as seen on picture:

I have made extra logging. I have also increased NRF_SDH_BLE_VS_UUID_COUNT in sdk_config. I have also increased my maximum characterstics and services. Hope you can help.

Regards Andreas 

[Dresse]

Hi Hung,

I thought to let you know, that right now, i'm testing with my phone as a peripheral, where I am using nrf connect app, and then I have entered my custom service UUID and custom characteristic. I'm not going to work until monday, to get the hearingaid. I haven't been able to use the correct hearingaid, since I made the custom code to characteristic, but I'm simulating it with my phone. But I don't think that should be a problem?

Now moving on to the test, I tested it by creating a new command for the CLI, where when I called the command, it would go straight to a sd_ble_gattc_read() with the exact handle i.e. 62, and this gave me the same response with 19 bytes.

I tried to build a new project with ble_app_uart, but that use an extra J-link right? I don't have that, but I don't know if it is easy to direct it to the normal uart connection, so that I can see it via PuTTy?

[Hung Bui]

I don't think you need any extra Jlink to test with ble_app_uart. If you have a nRF52 board and a programmer you should be able to do flash and test. We will try to test the sd_ble_gattc_read() function here as well. 

[Hung Bui]

Hi Dresse, 

I think I know what that 19 bytes for. If you have a look here 

It's the format of the 0x2803 attribute that you read at handle 62, it's the characteristic declaration, which include: characteristic properties (0x1A), characteristic value handle (0x003F) and the 128 bit UUID. 

Base on this you can extract the 128 bit UUID and extract the properties, value handle. 

[Dresse]

And now it works like a charm! Thanks Hung!

 

Fullscreen 20181123_121839putty.log Download

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2018.11.23 12:18:39 =~=~=~=~=~=~=~=~=~=~=~=


uart_cli:~$ BLE app with command line interface example started.
uart_cli:~$ Press Tab to view all available commands.
uart_cli:~$ connect 0uart_cli:~$ uart_cli:~$ <info> app: Scanning
uart_cli:~$ Connected to address: uart_cli:~$ 08 uart_cli:~$ AE uart_cli:~$ D6 uart_cli:~$ 81 uart_cli:~$ 3F uart_cli:~$ 26 uart_cli:~$ 
uart_cli:~$ <info> app: CENTRAL: Connected, handle: 0.
uart_cli:~$ gatt services 08:AE:D6:81:3F:26 <info> peer_manager_handler: Connection secured: role: Central, conn_handle: 0, procedure: Encryption
uart_cli:~$ gatt services 08:AE:D6:81:3F:26 Current MTU: 247
uart_cli:~$ gatt services 08:AE:D6:81:3F:26 MTU changed successfully
uart_cli:~$ gatt services 08:AE:D6:81:3F:26 <info> app: Data length updated to 251 bytes.
uart_cli:~$ gatt services 08:AE:D6:81:3F:26 <info> peer_manager_handler: Connection secured: role: Central, conn_handle: 0, procedure: Encryption
uart_cli:~$ gatt services 08:AE:D6:81:3F:26 Connection parameters update success
uart_cli:~$ gatt services 08:AE:D6:81:3F:26 uart_cli:~$ <info> app: GATT Services
uart_cli:~$ <info> app: Saving all Service DATA
uart_cli:~$ <info> app: Saving all Service DATA
uart_cli:~$ <info> app: Saving all Service DATA
uart_cli:~$ <info> app: Saving all Service DATA
uart_cli:~$ <info> app: Services count: 6
uart_cli:~$ Found service UUIDs: 
uart_cli:~$ UUID: 1801 type: 0x1
uart_cli:~$ UUID: 1800 type: 0x1
uart_cli:~$ UUID: AE62 type: 0x2
uart_cli:~$ UUID: 181C type: 0x1
uart_cli:~$ UUID: 180F type: 0x1
uart_cli:~$ UUID: 2EAF type: 0x3
uart_cli:~$ gatt characteristics 08:AE:D6:81:3F:26 AE62uart_cli:~$ <info> app: Number of characteristics: 2
uart_cli:~$ Characteristics: 
uart_cli:~$ UUID: B52E type: 0x4
uart_cli:~$ With these parameters:
uart_cli:~$ broadcast: 0 uart_cli:~$ read: 1 uart_cli:~$ write_wo_resp: 0 uart_cli:~$ write: 0 uart_cli:~$ notify: 1
uart_cli:~$ indicate: 0 uart_cli:~$ auth_signed_wr: 0
uart_cli:~$ UUID: AAA2 type: 0x5
uart_cli:~$ With these parameters:
uart_cli:~$ broadcast: 0 uart_cli:~$ read: 0 uart_cli:~$ write_wo_resp: 1 uart_cli:~$ write: 1 uart_cli:~$ notify: 0
uart_cli:~$ indicate: 1 uart_cli:~$ auth_signed_wr: 0
uart_cli:~$ <info> app: CENTRAL: Disconnected, handle: 0, reason: 0x13
uart_cli:~$ 

Just a recap for anyone else stumbling upon this problem:
If a custom characteristic, inside a custom service, has a different base UUID, then it needs to be read specifically with sd_ble_gattc_read, this is done as described in the posts above. Since you read on a characteristic declaration it has more than 16 bytes, as Hung described. That just needs to be decoded correctly and you are good to go!

[Dresse]

Hey Hung,

If I have some objections/corrections for the example project ble_app_interactive, how should I let you guys know? After working with it for a while, I have stumbled upon somethings, which I believe are errors in the code.