Change the transmission data structure of mesh chat messages

RE: Change the transmission data structure of mesh chat messages

Edvin — Fri, 13 Sep 2024 13:52:38 GMT

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

RE: Change the transmission data structure of mesh chat messages

greenK — Fri, 13 Sep 2024 06:38:38 GMT

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

RE: Change the transmission data structure of mesh chat messages

Edvin — Fri, 06 Sep 2024 13:59:40 GMT

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