BLE GATT Services

[nomve]

Hi,

I have a question related to GATT Services in BLE, so not strictly a nrf51 question although it's related to one of the examples. The example for the (Human) Thermometer from Github just broadcasts the data in the advertisement, since it's non-connectable. However, several resources say, for instance the Getting Started with Bluetooth book, say that GATT "establishes in detail how to exchange data over a connection". I'm a bit confused how the Thermometer example implements a GATT Service (BLE_UUID_HEALTH_THERMOMETER_SERVICE), where the devices aren't meant to connect. Is it because this service has just one mandatory characteristic, which is just "indicate"?

edit: After further reading, I see that it's possible to include attribute data in the advertising packets, but this is also only true if the broadcast property of a characteristic is allowed. But looking at the Thermometer Service this is not the case.

To maybe make it clearer what I want to ask: if I want to use a predefined service, would it be ok to broadcast service data in the adv. packet even if the broadcast property of a characteristic is not allowed? Or does it make more sense to define my own service where I could define the service data any way I would like?

[Petter Myhre]

I understand that this is confusing.

The example is just an example, it is not following the Health Thermometer Profile specification. But this is the one that is working with the nRF Temp apps. It shouldn't use the UUID of the Health Thermometer Service, it should have used a proprietary UUID.

In the SDK we have an example called ble_app_hts, this is actually following the Health Thermometer Profile specification. It doesn't include the termperature in the advertising packet, and it is connectable. The Health Thermometer Profile is mainly for use in healthcare applications.

I recommend you to use a proprietary UUID and define the behavior yourself.

[nomve]

Thank you very much for the response. After reading through the BLE documentation and giving it some thought I came to the same conclusion. A custom UUID is probably the most logical solution. However, we might use manufacturer data because a custom UUID is so large. And I don't want to ask too many additional questions related to scan responses.