setting BLE p_presentation_format not showing UTF8S

[Allen]

Hello,

I would like to change the default format of a custom characteristic to be a string format. The new characteristic is 8 characters long. This is the code;

        memset(&add_char_params, 0, sizeof(add_char_params));
        ble_gatts_char_pf_t cpfd = 
        {
            .format = BLE_GATT_CPF_FORMAT_UTF8S,
            .unit = 0x2BDE,
            .name_space = BLE_GATT_CPF_NAMESPACE_BTSIG,
            .desc = BLE_GATT_CPF_NAMESPACE_BTSIG
        };
        char init_value[MAX_HANDSHAKE_STRING_LEN] = {0};
        add_char_params.p_init_value = (uint8_t*)init_value;
        add_char_params.init_len =
        add_char_params.max_len = sizeof(init_value);
        add_char_params.char_props.read = true;
        add_char_params.read_access = SEC_OPEN;
        add_char_params.char_props.write = true;
        add_char_params.write_access = SEC_OPEN;
        add_char_params.p_presentation_format = &cpfd;
        add_char_params.uuid = BLE_UUID_CHARAC_ECG_HANDSHAKE;

        err_code |= characteristic_add(
            m_ecg_service.data_svc_handle, &add_char_params, &(m_ecg_service.handshake_handles));

Neither the desktop or mobile nRFConnect programs indicate this is a string value. Both display the initial value as binary. I also tried changing the namespace to UNKNOWN and unit=0 but that did not work either.

[Edvin]

Hello Allen,

There is no setting saying whether a characteristic is a string or a binary value. At the end of the day they are all binary values, and you need to know what you input on one side, and how to interpret it on the other side. 

One example for this is the ble_app_uart and ble_app_uart_c example pair from the nRF5 SDK. The values are just sent as an array of bytes, but it is the application that decides to output these values as characters on the UART when they receive data from the connected device. 

Best regards,

Edvin

[Allen]

What is the purpose of the p_presentation_format field is not to aid in communicating the intended data types?

[Edvin]

I didn't really see it before.

From what I can tell, and where it is used in the SDK, this is not really used in any of our examples, and it doesn't look like it is something that will be transferred over BLE. It is only used internally by the local device in the serialization example. 

Can you please tell me a bit about why you are asking this question. Perhaps there is something that I don't understand, or that there is a misunderstanding. I don't really see why you need to set. As long as your peripheral application decides on what format the data is (without specifying it anywhere), and the central interprets the data in the same way, I don't see the problem. Please enlighten me.

Best regards,

Edvin

[Allen]

When using the Desktop Bluetooth Low Energy application you can only enter hex byte arrays. In the mobile application you can choose the data type. I was hoping that adding this field would inform the application about the intended data type.

BTW, this is transmitted over BLE. It appears in the BLE application when you open the characteristic where it is set.

[Edvin]

Allen said:

When using the Desktop Bluetooth Low Energy application you can only enter hex byte arrays. In the mobile application you can choose the data type.

Yes. That is just a feature in the mobile application that is not present in the desktop application. It has nothing to do with the p_presentation_format parameter.

The phone just translates from e.g. a string to byte format. 

You can see that if you type the string "123" and then the byte format: "31 32 33" it will result in the exact same data being transferred (0x31 is the same as  "1", 0x32 is the same as "2" and 0x33 is the same as "3").

Best regards,

Edvin