in the SIlicon Labs BLE stack, characteristics with or without the attribute type="user" are handled in different event handlers of the main loop. Why is that? See an example of my GATT database here, where the heart rate service characteristics value field are of type=user, and the Health Thermometer Service characteristic's value field have no attribute with type="user".
<service uuid="180D" advertise="true"> <!-- Heart Rate Measurement : Mandatory --> <!-- https://developer.bluetooth.org/gatt/characteristics/Pages/CharacteristicViewer.aspx?u=org.bluetooth.characteristic.heart_rate_measurement.xml --> <characteristic uuid="2A37" id="HEART_RATE_HEART_RATE_MEASUREMENT" > <properties notify="true" /> <value type="hex" length="8" type="user"></value> <!-- TODO:: Set value or change type to "user" and add handling for it --> </characteristic> <!-- Body Sensor Location : Optional --> <!-- https://developer.bluetooth.org/gatt/characteristics/Pages/CharacteristicViewer.aspx?u=org.bluetooth.characteristic.body_sensor_location.xml --> <characteristic uuid="2A38" id="HEART_RATE_BODY_SENSOR_LOCATION" > <properties read="true" /> <value type="hex" length="1" type="user"></value> </characteristic> <!-- Heart Rate Control Point : Conditional --> <!-- https://developer.bluetooth.org/gatt/characteristics/Pages/CharacteristicViewer.aspx?u=org.bluetooth.characteristic.heart_rate_control_point.xml --> <characteristic uuid="2A39" id="HEART_RATE_HEART_RATE_CONTROL_POINT" > <properties write="true" /> <value type="hex" length="1" type="user"></value> </characteristic> </service> <!-- Health Thermometer Service --> <!-- https://developer.bluetooth.org/gatt/services/Pages/ServiceViewer.aspx?u=org.bluetooth.service.health_thermometer.xml --> <service uuid="1809" advertise="true"> <description>Health Thermometer</description> <!-- Temperature Measurement --> <!-- https://developer.bluetooth.org/gatt/characteristics/Pages/CharacteristicViewer.aspx?u=org.bluetooth.characteristic.temperature_measurement.xml --> <characteristic uuid="2a1c" id="GATTDB_HEALTH_THERMOMETER_TEMPERATURE_MEASUREMENT"> <properties indicate="true" /> <!-- 1 byte flags + 4 bytes temp value --> <value length="5" /> </characteristic> </service>
"user" type characteristics are more flexible. For example, the maximum length for non-user characteristics is 255 but user-type characteristics can be up to 512 bytes long.
Another example: when a normal (non-user) characteristic is read, the stack will automatically respond to the client with the most recent value that has been written into the GATT database. The application at the peripheral side is not even aware that someone has read the value. (There is no event generated when client reads a non-user characteristic).
Imagine that you want to implement a service that allows client to read the value of some sensor. The reading happens only when requested by client so you don't want to use notifications or indications in this case. If you declare the characteristic as user-type, you can start reading the sensor value when you get the evt_gatt_server_user_read_request event. Then you pass the result to the client using cmd_gatt_server_send_user_read_response.
This is just one example of how the user-type characteristic can be used.
In the example GATT XML that you attached, there is not necessarily any reason to use user-type characteristics for the heart rate service. For example, the old BGScript heart-rate example in our 1.0.4 SDK used non-user characteristics to implement the same service.
So as a conclusion: user-type characteristics can be used if:
1) you need to support longer characteristics than 255 bytes
2) you need to have more control over what happens when characteristics are read or written
There is a separate event when client is reading or writing a user-type characteristic. This is a design choice made by our BLE stack developers and I think it will help you make your application code more structured, especially if you are mixing both user and non-user characteristic in one application.
Hope this clears things up a bit!
Hi JaakkoV, thanks for the great answer.