Communicating nrf52 with ubuntu and bluez stack issue

[Nagesh]

I am trying to communicate between peripheral device (nordic nRF52840)  with another device (let us say ubuntu device) with ubunutu as OS and Bluez bluetooth stack. I have implemented gatt server using bluez stack on ubuntu device. The both devices are acting as server and client with same service names (vendor uuid) and characteristics with discriptor. I am able to connect with peripheral device and then peripheral device is looking for particular gatt service on ubuntu device where is the problem coming. The peripheral is issuing "Find by Type Value Request" for the particular service (I guess to get handles and attribute values) where this is failing on ubuntu device. Ubuntu device is responding with "Request not supported err 0x6" as response to that command sent from the peripheral for primary service discovery. I am not sure if Bluez supports "Find by Type Value" request. I have couple of questions here.

- Does/can peripheral support "Read by Group Type Request" and is that can be used for discovering primary services on other device e.g. having bluez stack?

- Is there any workaround or solution you can suggest to get rid of this issue ?

Note that I am able to read and write characteristic from ubuntu device and am also able to discover the primary services and characteristics of peripheral.

[Håkon Alseth]

Hi,

 

- Does/can peripheral support "Read by Group Type Request" and is that can be used for discovering primary services on other device e.g. having bluez stack?

This is the normal procedure used for generic discovery upon connection, where the central reads the peripherals GATT database.

- Is there any workaround or solution you can suggest to get rid of this issue ?

I suspect that you get a "not supported err 0x6" is due to the specific characteristic that you're trying to read. If you try to read a characteristic which does not have a read properties for instance, or a characteristic that requires a certain security level, I suspect you might get this sort of return code.

Do you have a sniffer trace available showing the behavior? You can use wireshark + nrf-sniffer to capture.

 

Cheers,

Håkon

[Nagesh]

Thats great to hear that "Read by Group Type Request" is possible for discovering of services and characteristics of server.  I was exploring zephyr and got to know that "bt_gatt_discover" is the only api used for this purpose (correct if this is nor right). The description of this is,

"Primary Service Discovery: Procedure allows to discover specific Primary Service based on UUID. Include Service Discovery: Procedure allows to discover all Include Services within specified range. Characteristic Discovery: Procedure allows to discover all characteristics within specified handle range as well as discover characteristics with specified UUID. Descriptors Discovery: Procedure allows to discover all characteristic descriptors within specified range".

From this can we say or confirm that primary service discovery is particularly "Find by Type Value Request" whereas include service discovery is "Read by Group Type Request" based ? will this be similar for characteristic and descriptor discovery ?

This is more to zephyr question but grateful if you can give suggestions in this regard.

[Håkon Alseth]

Hi,

 

From this can we say or confirm that primary service discovery is particularly "Find by Type Value Request" whereas include service discovery is "Read by Group Type Request" based ? will this be similar for characteristic and descriptor discovery ?

This is more to zephyr question but grateful if you can give suggestions in this regard.

This is not a zephyr question, but a bluetooth LE question.

"Find by Type Value Req" will ask for a range of handles, normally 0x0001 to 0xFFFF. The peripheral will then respond with the range that it has populated, for instance up to 0x000a.

The central will then "Read by type request" to read out each handle within the range previously responded by the peripheral, as a peripheral can have "holes" in the handles it uses (can skip 0x0007 for instance). As an example: The central can ask for handles 0x0003 to 0x0007 in one request and the peripheral replies that it has 0x0003 to 0x0006 (not 0x0007), then read the remainder 0x0008 to 0x000a will be discovered in a upcoming request.

Now you have all the handles of your peripheral, but you do not have the information located in each handle, like the "Device Name". To get this, you do a normal "Read request".

 

I'd recommend doing a couple of captures with the nRF-sniffer (uses Wireshark as frontend) to see how a BLE connection is made, so that you can look into the bits and bytes.

 

Best regards,

Håkon