BLE large Write turns to gibberish

[Jonas Lien]

Greetings!

I have a central that's writing BLE messages to a peripheral. The characteristic on the peripheral is a 32-byte array, and my experiment is to write 32 bytes from the Central to the Peripheral without extending the Data Length, but only extending the ATT MTU. My understanding is that this is plausible, GATT will only need to send more messages within the same connection.

I am attempting to write:

Where bt_write_to_characteristic looks like:

and closely follows setup for the NCS NUS sample.

This is then seen to be split up into two writes on the peripheral (which makes sense since I didn't edit the DLE and it should remain 27 bytes long), and is split up into a message of 18 bytes and a message of 14 bytes (equals 32 bytes, so still makes sense). What then baffles me, is that the first message is entirely correct while the second message is seemingly gibberish:

This is output from the peripherals characteristic write callback:

Why would this be? Any idea what might be wrong? And why was the message split up into 18 and 14, and not 20 & 12, which would have made more sense regarding standard att payload is 20?

(I know i am actually overwriting the beginning of the characteristic value after receiving the BLE writes, but ignore that for now  also, I know it's peripheral functionality so ignore the fact its wrongly called 'beacon'  )

Current bluetooth related Kconfigs on both Central and Peripheral:

CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=n

CONFIG_BT_RX_BUF_LEN=255

CONFIG_BT_ATT_TX_MAX=10

CONFIG_BT_ATT_PREPARE_COUNT=2

CONFIG_BT_CONN_TX_MAX=10

CONFIG_BT_L2CAP_TX_BUF_COUNT=10

CONFIG_BT_L2CAP_TX_MTU=247

CONFIG_BT_L2CAP_RX_MTU=247

CONFIG_BT_L2CAP_DYNAMIC_CHANNEL=y

CONFIG_BT_CTLR_RX_BUFFERS=2

CONFIG_BT_CTLR_TX_BUFFERS=10

CONFIG_BT_CTLR_TX_BUFFER_SIZE=251

Looking forward to your response!

Best regards,

Jonas

[Simonr]

Hi Jonas

I'm sorry about the poor response, but I have not had sufficient time to take a good look at your issue today, and will do so first thing tomorrow morning. I should be able to provide some better assistance/support by tomorrow. Thank you for your patience!

Best regards,

Simon

[Simonr]

Hi

The send function seems to be done correctly, but the way you receive and interpret the data is what's causing these garbage values in the second packet.

It seems like you're ignoring the offset that tells the receiver what to look for in the second packet, which is why you only see the first packet correctly. You'll need to take the fact that this is a continuation of data so the data from the second packet is what is printed, and not just random data. Also, where do you store this incoming data beacon_data.fw? Is it stored in RAM or Flash?

Best regards,

Simon

[Jonas Lien]

Hi Simon, and thanks for your reply

beacon_data.fw is just a struct stored in RAM at runtime.

How do I account for the offset that you are talking about? It seems there is something about the transmit process im not fully getting.

BR,

Jonas

[Simonr]

Hi again Jonas

I'm sorry about the delayed reply, but I've discussed this with a colleague, and it seems that, honestly, it doesn't seem like we've tested long prepared writes like this properly. Can you upload your project or the necessary code snippets to do a long write so we can test this on our end, as we'd like to give the correct explanation on how to handle this offset.

Best regards,

Simon

[Jonas Lien]

Hi again Simon,

I think I've basically already given you the relevant code snippets in the top post, but maybe you can use any of your NCS samples that does BLE writes and just increase ATT MTU? I'm fine with any example of writing a bigger object than what the DLE is set for.

I know your throughput sample operates with varying degree of data length, but there it is used bt_gatt_write_without_response, where as I'm interested in bt_gatt_write which also gives a response/ack. The throughput sample also just uses "offset=0" in its params, so I'm not sure what differently I should do.

Hope to hear from you soon

Best regards,

Jonas