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]

So, I don't quite understand what you mean about base uuid. I have attached one of the custom uuid, that is in the hearing aid.

 

I still have my problem of not being able to see the custom characteristics inside the custom service, well I can see it, but I can't see the specific uuid for it. But if I understand what you said correctly, because my custom characteristics, does not have the same base uuid as the service, it can't see it?

And you are suggesting me to test with ble_app_uart, but do you mean ble_app_uart_c? Because my nrf52 dk is acting as a central and connecting with a peripheral.

[Hung Bui]

Hi Dresse, 

Yes you can test with the ble_app_uart. The GAP role is a little bit different but the service discovery from the GATT client is the same. 
We have the base UUID which is the 128 bit UUID and the short 16 bit UUID which is byte 12 and 13 inside the 128 bit UUID. This is explained in the description of sd_ble_uuid_vs_add() 

You can use nRF Connect on the phone and do service discovery for the ble_app_uart you can see how the service and characteristic share the same base UUID and only byte 12 and 13 are different. 

In your att table, I can see that all characteristics and service have different base UUID. 

In this case you would need to modify the ble_m.c library to support UUID read on the characteristic discovery, the same way as we have in the service discovery. Please have a look at  on_primary_srv_discovery_rsp() and on_read_rsp() function, where we do a sd_ble_gattc_read() on each service that has the uuid.type == BLE_UUID_TYPE_UNKNOWN

You would need to add the code to do the same when doing characteristic discovery. 

I'm a little bit busy at the moment, if I managed to have time I can try to implement but I would suggest you to try first. 

[Dresse]

Thanks, that explains a lot! I will try to implement it myself.

[Dresse]

I have been trying to implement it myself, but I am kind of stuck. Inside on_characteristics_discovery_rsp, I have made a check each characteristic that has uuid.type == BLE_UUID_TYPE_UNKNOWN:

        // Save characteristics data.
       for (uint8_t i = offset; i < bytes_to_copy; i++)
       {
           m_srv_char.char_data[i].decl_handle      = p_char_disc_rsp_evt->chars[i].handle_decl;
           m_srv_char.char_data[i].value_handle     = p_char_disc_rsp_evt->chars[i].handle_value;
           m_srv_char.char_data[i].uuid             = p_char_disc_rsp_evt->chars[i].uuid;
           m_srv_char.char_data[i].notify           = p_char_disc_rsp_evt->chars[i].char_props.notify;
           m_srv_char.char_data[i].cccd_desc_handle = 0;

       }

       // If service UUID type is unknown, then try to search for the 128-bit UUID.
       for (uint8_t i = offset; i < bytes_to_copy; i++)
       {
    	   if (m_srv_char.char_data[i].uuid.type == BLE_UUID_TYPE_UNKNOWN){
    		   NRF_LOG_INFO("Characteristic is unknown");
    		   m_vendor_uuid_read_char = true;
			   // Look for characteristic 128-bit UUID.
			   err_code = sd_ble_gattc_read(conn_handle, m_srv_char.char_data[i].decl_handle, 0);
			   APP_ERROR_CHECK(err_code);
			   return;
			 }

           // If characteritics is last.
           if (i == (count - 1))
           {
               m_vendor_uuid_read_char = false;
               // Print services UUID. When you first discover services, the 128-bit UUIDs may not be displayed.
               // In such case, you should rediscover the services.
               uuid_print(p_ble_gattc_evt->conn_handle, mp_device_srv[conn_handle]->services);
           }
           offset++;
       }

After it gets all characteristics, and the types, it check whether one of them is VS UUID, then it calls err_code = sd_ble_gattc_read(conn_handle, m_srv_char.char_data[i].decl_handle, 0);, with decl_handle for the characteristic which type is unknown. I also made a new bool m_vendor_uuid_read_char, so that when i enter on_read_rsp, I know what I asked for. Inside on_read_rsp, I kinda made the same af with service discovery:

    else if(m_vendor_uuid_read_char){
        // Save characteristics uuid data.
       for (uint8_t i = 0; i < m_srv_char.count; i++)
       {
    	   NRF_LOG_INFO("Handle search: %d And reached handle: %d", m_srv_char.char_data[i].decl_handle, p_read_rsp->handle)
    	   if(p_read_rsp->handle == m_srv_char.char_data[i].decl_handle){
    		   NRF_LOG_RAW_INFO("Data len: %d Read data:\r\n", p_read_rsp->len);
			  for (uint8_t i = 0; i < p_read_rsp->len; i++)
			  {
				  NRF_LOG_RAW_INFO("0x%X ", p_read_rsp->data[i]);
			  }
			  NRF_LOG_RAW_INFO("\r\n");
    		  memcpy(uuid.uuid128, p_read_rsp->data, sizeof(uuid.uuid128));
    		  err_code = sd_ble_uuid_vs_add(&uuid, &m_srv_char.char_data[i].uuid.type);
    		  APP_ERROR_CHECK(err_code);
    		  m_srv_char.char_data[i].uuid.uuid = (uuid.uuid128[13]<<8)+uuid.uuid128[12];
    		  NRF_LOG_INFO("m_srv_char.char_data.uuid: %X", m_srv_char.char_data[i].uuid.uuid);
    		  break;
    	   }
       }


       for (uint8_t i = 0; i < m_srv_char.count; i++)
       {
    	   if (m_srv_char.char_data[i].uuid.type == BLE_UUID_TYPE_UNKNOWN)
			  {
    		   m_vendor_uuid_read_char = true;
				  // Look for service 128-bit UUID.
				  err_code = sd_ble_gattc_read(conn_handle, m_srv_char.char_data[i].decl_handle , 0);
				  APP_ERROR_CHECK(err_code);
				  return;
			  }

    	   if(i == (m_srv_char.count -1)){
    		   NRF_LOG_INFO("Characteristics count: %d", m_srv_char.count);
    		   // Print services UUID. When you first discover services, the 128-bit UUIDs may not be displayed.
    		   // In such case, you should rediscover the services.
    		   m_vendor_uuid_read_char = false;
    		   uuid_char_print(m_srv_char);
    	   }
       }
       return;
    }

But now im facing some problems, my data length in p_read_rsp->len, is 19 when receiving the response. I think it might have to do that, i'm asking for the handle of the characteristic declaration, and I it might send more data, than just the char uuid. I'm basically doing the same as in when doing custom Service Discovery. And I have also uploaded my log file for a full overview.

Fullscreen 20181122_152218putty.log Download

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2018.11.22 15:22:18 =~=~=~=~=~=~=~=~=~=~=~=


uart_cli:~$ BLE app with command line interface example started.
uart_cli:~$ Press Tab to view all available commands.
uart_cli:~$ 
  advertiseballocbonded_devicesclear
  clear_devicescliconnectconnected_devices
  device_namedevicesdisconnectgatt
  historykey_replylogmpu
  numericpairparametersprivacy
  queueremove_bondresizescan
uart_cli:~$ connect 1uart_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:~$ <info> peer_manager_handler: Connection secured: role: Central, conn_handle: 0, procedure: Encryption
uart_cli:~$ Current MTU: 247
uart_cli:~$ MTU changed successfully
uart_cli:~$ <info> app: Data length updated to 251 bytes.
uart_cli:~$ <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: Enters VS UUID Discovery
uart_cli:~$ Data len: 16 Read data:
uart_cli:~$ 0xFF uart_cli:~$ 0xEE uart_cli:~$ 0xDD uart_cli:~$ 0xCC uart_cli:~$ 0xBB uart_cli:~$ 0xAA uart_cli:~$ 0x0 uart_cli:~$ 0x80 uart_cli:~$ 0x0 uart_cli:~$ 0x10 uart_cli:~$ 0x0 uart_cli:~$ 0x0 uart_cli:~$ 0xA0 uart_cli:~$ 0xAA uart_cli:~$ 0x0 uart_cli:~$ 0x0 uart_cli:~$ <info> app: Service type: 0
uart_cli:~$ <info> app: Enters VS UUID Discovery
uart_cli:~$ Data len: 16 Read data:
uart_cli:~$ 0x63 uart_cli:~$ 0xA0 uart_cli:~$ 0x39 uart_cli:~$ 0x38 uart_cli:~$ 0xC8 uart_cli:~$ 0xE8 uart_cli:~$ 0xB1 uart_cli:~$ 0x87 uart_cli:~$ 0xD1 uart_cli:~$ 0x43 uart_cli:~$ 0xC2 uart_cli:~$ 0xC4 uart_cli:~$ 0x62 uart_cli:~$ 0xAE uart_cli:~$ 0x23 uart_cli:~$ 0xA uart_cli:~$ <info> app: Service type: 0
uart_cli:~$ <info> app: Enters VS UUID Discovery
uart_cli:~$ Data len: 16 Read data:
uart_cli:~$ 0x5A uart_cli:~$ 0xBF uart_cli:~$ 0x9F uart_cli:~$ 0xD9 uart_cli:~$ 0x68 uart_cli:~$ 0x43 uart_cli:~$ 0xF3 uart_cli:~$ 0xAC uart_cli:~$ 0x74 uart_cli:~$ 0x4F uart_cli:~$ 0x53 uart_cli:~$ 0x21 uart_cli:~$ 0xAF uart_cli:~$ 0x2E uart_cli:~$ 0x77 uart_cli:~$ 0x56 uart_cli:~$ <info> app: Service type: 0
uart_cli:~$ <info> app: Services count: 7
uart_cli:~$ Found service UUIDs: 
uart_cli:~$ UUID: 1801 type: 0x1
uart_cli:~$ UUID: 1800 type: 0x1
uart_cli:~$ UUID: AAA0 type: 0x2
uart_cli:~$ UUID: 181C type: 0x1
uart_cli:~$ UUID: 180F type: 0x1
uart_cli:~$ UUID: AE62 type: 0x3
uart_cli:~$ UUID: 2EAF type: 0x4
uart_cli:~$ gatt characteristics 08:AE:D6:81:3F:26 AE62uart_cli:~$ <info> app: Count: 2
uart_cli:~$ <info> app: Characteristic is unknown
uart_cli:~$ <info> app: Enters VS UUID Discovery
uart_cli:~$ <info> app: Handle search: 62 And reached handle: 62
uart_cli:~$ Data len: 19 Read data:
uart_cli:~$ 0x1A uart_cli:~$ 0x3F uart_cli:~$ 0x0 uart_cli:~$ 0x87 uart_cli:~$ 0xFC uart_cli:~$ 0x4D uart_cli:~$ 0xEF uart_cli:~$ 0x6C uart_cli:~$ 0x1 uart_cli:~$ 0x30 uart_cli:~$ 0x94 uart_cli:~$ 0x64 uart_cli:~$ 0x47 uart_cli:~$ 0x2 uart_cli:~$ 0x30 uart_cli:~$ 0x2E uart_cli:~$ 0xB5 uart_cli:~$ 0xFA uart_cli:~$ 0x6E uart_cli:~$ 
uart_cli:~$ <info> app: m_srv_char.char_data.uuid: 247
uart_cli:~$ <info> app: Enters VS UUID Discovery
uart_cli:~$ <info> app: Handle search: 62 And reached handle: 65
uart_cli:~$ <info> app: Handle search: 65 And reached handle: 65
uart_cli:~$ Data len: 19 Read data:
uart_cli:~$ 0x2 uart_cli:~$ 0x42 uart_cli:~$ 0x0 uart_cli:~$ 0x33 uart_cli:~$ 0xC2 uart_cli:~$ 0x53 uart_cli:~$ 0x49 uart_cli:~$ 0xA8 uart_cli:~$ 0x9B uart_cli:~$ 0x3B uart_cli:~$ 0xB1 uart_cli:~$ 0xB9 uart_cli:~$ 0x4B uart_cli:~$ 0xB6 uart_cli:~$ 0x70 uart_cli:~$ 0x69 uart_cli:~$ 0x6F uart_cli:~$ 0xEE uart_cli:~$ 0xEB uart_cli:~$ 
uart_cli:~$ <info> app: m_srv_char.char_data.uuid: B64B
uart_cli:~$ <info> app: Characteristics count: 2
uart_cli:~$ Found characteristics UUID: 
uart_cli:~$ UUID: 247 type: 0x5
uart_cli:~$ UUID: B64B type: 0x6
uart_cli:~$ 

[Hung Bui]

Hi,

It's pretty strange to see 19 bytes. I can see the UUID is actually inside that 19 bytes , started from 0x87 ended with 0x6E . It's your first characteristic's UUID.

Could you try to open a new application and try just to do a sd_ble_gattc_read() on that exact handle of the characteristic and see what response you have 16 or 19  bytes ? Then test with a known example (ble_app_uart) so we can reproduce here.