Functioning of Characteristic Presentation Format Descriptor (CPFD)

[Sreejith Sundh]

Hi,

I would like to know the functioning of CPFD (I would like to represent the characteristic value as IEEE754 float32) I am not aware of how can I implement this. for example, if I am measuring the acceleration (float value), but I would like to send the data as int32 type (which following method should I chose in case of CPFD?)

1. Convert the float measuured value to corresponding hexadecimal value according to IEEE754 Floating point representation and mention in the descriptor that I uses IEEE754 so that, master can convert back it in to the float point

2. or I can use float datatype for the characteristic value by mentioning CPFD as #define BLE_GATT_CPF_FORMAT_FLOAT32 (according to  Characteristic Presentation Formats (nordicsemi.com) )?

all together I just want to know what is CPFD, how to implement this and how this helps me with my project of reading acceleration value (with fractional value).

 

Thanks in advance for your time and effort.

with Regards,

Sreejith

[ovrebekk]

Hi Sreejith

If you look at any of the existing service implementations (such as ble_nus.c) you will find an init function that sets up the different characteristics. 

For each characteristic there will be an init structure of type ble_add_char_params_t, typically called something like add_char_params in the code. 

This struct has a field of type p_presentation_format, and if you point this to a struct of type ble_gatts_char_pf_t you can set up the presentation format descriptor as needed for this particular characteristic. 

The code should look something like this:

ble_gatts_char_pf_t cpfd = {.exponent = 1,
                            .format = BLE_GATT_CPF_FORMAT_FLOAT32,
                            .unit = 0x2715,
                            .name_space = BLE_GATT_CPF_NAMESPACE_BTSIG,
                            .desc = BLE_GATT_CPF_NAMESPACE_BTSIG};
add_char_params.p_presentation_format = &cpfd;

In order to figure out what to put in the unit field you can get an overview of the various BT Sig defined units here. 

Best regards
Torbjørn

[Sreejith Sundh]

Hi Torbjørn,

Many thanks for the updates. It really helping me....

As part of this ticket I would like to ask one more question, is it possible for sending float value (with fractional value) over ble? Ultimately my requirement to send the original data of acceleration measured from the sensor. is it possible?

Thanks and Regards,

Sreejith

[ovrebekk]

Hi Sreejith

When creating your own proprietary service there is no limit to the types of data that you can send. In the end you are just sending a byte array, and whatever data you want to put into that array is up to you. 

The important aspect is that you are interpreting the data in the same way on both sides of the link. Normally you would need some code to handle the conversion from a byte array to whatever data fields you want. 

The easiest way to do this is to create a union between a byte array, and a custom struct containing the actual data fields that you want to use. 

Best regards
Torbjørn

[Sreejith Sundh]

Hi Torbjørn,

Yes I am planning to combine the value, timestamp and alert. would it be fine? If I am using 32 bit for value, 32 bit for timestamp and 8 bit for alerts, then client can seperate it accordingly on the client side.( I hope the CGMS example in nRF5 SDK works exactly same like this?)

Thank you for your response on this ticket, I have included the CPFD, once I included CPFD with FLOAT32 (IEEE754) it shows a value in the characteristics (is that indicates the representation for the IEEE754, can we verify that  "it is the right representation" just for cross checking? ( Yes the client will checks for CPFD in order to decode the data). 

even though I am combining all three fields together in the characteristics, Is it possible to control the characteristic notify property only depends on the alert flag field? because sometimes I just want to notify only if there is any alert flag obtained. If so what changes should I implement in the notification property of the characteristic?

Thanks and Regards,

Sreejith

[ovrebekk]

Hi Sreejith

Sorry for the slow response, I have been out in vacation for a couple of weeks. 

Sreejith Sundh said:

Yes I am planning to combine the value, timestamp and alert. would it be fine?

Yes, this should work fine. 

The only thing to be aware of is that when you are combining fields of different sizes in the struct you should declare it packed, otherwise each field might be aligned to that of the largest field (meaning your 8 bit alert field would occupy 32 bits in the struct rather than 8). 

Sreejith Sundh said:

I have included the CPFD, once I included CPFD with FLOAT32 (IEEE754) it shows a value in the characteristics (is that indicates the representation for the IEEE754, can we verify that  "it is the right representation" just for cross checking?

You mean you want to verify that the raw value of the characteristic decodes to the correct floating point value according to the IEEE754 specification?

If so you should be able to use something like this online IEEE754 converter to check if the value is correct. 

Sreejith Sundh said:

even though I am combining all three fields together in the characteristics, Is it possible to control the characteristic notify property only depends on the alert flag field?

No, the notify property only allows the client to set a single bit, in order to enable or disable notifications. You can't send any additional information through the CCCD. 

In the end it is the server device (the peripheral normally) that decides when to send notifications. Either you can use a separate characteristic to allow the client to configure when the server should send notifications, or the server would have to expose two different characteristics of the same type, where the client can subscribe to one to get updates all the time, or subscribe to the other one to only get updates when the alert flag field is set.

Best regards
Torbjørn