Hi,
We have a device configured as a peripheral and want to provide the user with the peer device name typically connected to it, like the device name. Typically a phone will connect to our device. Is this possible? If so, do you have any examples in the nrf Connect SDK showing how this is accomplished?
Thanks
Hi kpreiss,
If the central device hosts a GATT Server, there will be a mandatory GAP Service, where the Device Name can be read (refer to Bluetooth Specification, Vol 3, Part C, Section 12).
I am trying to understand the spec to see if the GATT Server is always required. I will get back to you on that soon.
Similarly, the GATT Server could also include an optional Device Information Service, where the Device Name is also a characteristic.
Hieu
Ok, thank you. What is the process for finding the central's server characteristics? Can the central be discovering the characteristics in the peripheral GATT server at the same time the peripheral is discovering the characteristics in the central GATT server? Do you have nrf Connect SDK examples of this?
kpreiss said:What is the process for finding the central's server characteristics?
The process for the Peripheral discovering the Central's GATT Server is exactly the same as the one for the Central discovering the Peripheral's GATT Server.
kpreiss said:Can the central be discovering the characteristics in the peripheral GATT server at the same time the peripheral is discovering the characteristics in the central GATT server?
I am not actually very sure myself. Is this simultaneous discovery an important requirement? Discovering a Central's GATT Server is usually very fast, because such server usually only has the GAP Service.
kpreiss said:Do you have nrf Connect SDK examples of this?
You can just refer to the GATT Client code in Central samples.
Hieu said:I am trying to understand the spec to see if the GATT Server is always required. I will get back to you on that soon.
A colleague helped me found that the spec does require that the Central has a GATT Server. You can expect to find the GAP Service and Device Name Characteristic.
Thank you Hieu,
The simultaneous discovery is a requirement because we already have 3rd party developers who are querying the GATT server in the peripheral. If it's not supported, would an error be returned informing the higher level application to retry characteristic discovery?
Hi kpreiss,
Sorry, this took a while.
If I understand your concern correctly, it's that you cannot control when the 3rd party device will initiate service discovery, and thus simultaneous discoveries might happen, correct?
I could only go into a little depth with the NCS-based Peripheral. I cannot comment on the capability of the Central. I can only say that the Bluetooth Spec does not forbid simultaneous discovery.
For the Peripheral app here, the Zephyr Bluetooth Host allocates a new buffer each time there is a new GATT request. So, the failure conditions are somewhat like mallocs, where a lot of requests have been queued up.
Meanwhile, the remote Client can send at most one request at a time, and the app's own Discovery will also only queue one request at a time.
Additionally, the Central's GATT Server usually contains just the bare minimum GAP characteristics, so the discovery of the Central's Server will complete quickly.
Considering all of that, as long as EATT is not being used and the application does not perform other requests while performing the discovery, it shouldn't be an issue.
I setup a slightly modify pair of Peripheral UART and Central UART samples, where both devices try to discovery service as soon as they are connected. It works fine.
c328916_concurrent_discovery.zip
Please remember that this is meant to be a demonstration and not a representative for all cases. Thorough testing of your system is always necessary.
