This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE large Write turns to gibberish

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 Slight smile also, I know it's peripheral functionality so ignore the fact its wrongly called 'beacon' Smile )

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

Parents
  • 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

  • Hi Simon, and thanks for your reply Slight smile

    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

Reply Children
No Data
Related