Change the transmission data structure of mesh chat messages

Hi

This is a project that reads sensor data and transmits it to the phone. Currently, the sensor data is read and transmitted to the app.

However, if there is 0x00 in the middle of the data, the data after that cannot be transmitted and the message transmission is completed.

How can I prevent this and transmit the desired data (20 bytes)?
Please advise if there is a solution or reference.

Best regards
GreenK

  • Hello,

    The reason why it stops at 0x00 is that the chat sample is designed to send strings that always end with 0x00 or '/0' as you can see here:

    static const uint8_t *extract_msg(struct net_buf_simple *buf)
    {
    	buf->data[buf->len - 1] = '\0';
    	return net_buf_simple_pull_mem(buf, buf->len);
    }

    look in the chat_cli.c and look at how it is handled. I must admit I don't know it's quirks, but you need to decide something that decides when to send the message. Since this is a chat program, it doesn't know the length up front. But you need to write something that decides when to call send_message_reply(), not dependent on 0x00.

    Best regards,

    Edvin

  • Hi Edvin

    I looked into chat_cli.c as you advised.
    Currently, we are using "int bt_mesh_chat_cli_private_message_send()" to send sensor data.

    So, in "bt_mesh_chat_cli_private_message_send() / net_buf_simple_add_mem()", I applied a fixed buffer length (20byte) instead of strnlen, and confirmed that it is transmitted even if there is 0x00 data in the middle.

    Thank you for your advice, and please advise if it affects other parts if used as above.

    Best regards,

    greenK

  • I think that is correct. The Bluetooth part of this doesn't usually care about the content of it's data buffers, so these 0-terminated strings are usually just a way to determine that a text string has reached it's end. All the bluetooth buffers are specified by length, so if you are able to send it correctly now, and you can see it from the other side, it should be fine.

    Best regards,

    Edvin

Related