Communicating nrf52 with ubuntu and bluez stack issue

RE: Communicating nrf52 with ubuntu and bluez stack issue

Håkon Alseth — Thu, 09 Aug 2018 09:00:57 GMT

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

RE: Communicating nrf52 with ubuntu and bluez stack issue

Nagesh — Wed, 08 Aug 2018 13:07:05 GMT

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.

RE: Communicating nrf52 with ubuntu and bluez stack issue

Håkon Alseth — Wed, 08 Aug 2018 11:29:27 GMT

Hi,

[quote user=""]- 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?[/quote]

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

[quote user=""]- Is there any workaround or solution you can suggest to get rid of this issue ?[/quote]

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