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

GATT timeout executing long write with nRF Connect

I successfully built the example peripheral project "experimental_ble_app_queued_writes" from nRF5_SDK_12.0.0_12 and successfully downloaded the app to a nRF52832 development board with subsequent automatic activation of fast advertising. I can successfully connect to the resulting "Queued_Write" peripheral with the nRF Connect software that interfaces with a nRF51 dongle. I can successfully access the "UART over BLE" service with the associated single characteristic that is supposed to support long writes. However, when I actually try to write some number of bytes to this characteristic, nRF Connect eventually times out with a "Received a Gatt timeout" message. My assumption would be that this should work correctly with no user modifications since it is Nordic example code running on Nordic hardware and interfacing with the nRF Connect software also running on Nordic hardware. What's going wrong? Thanks for the help.

  • FormerMember
    0 FormerMember

    When I test nRF Connect (PC) here, queued writes work. I tested with the example experimental_ble_app_queued_writes, SDK 12.0.0.

    Did you follow the test description on the info center?

    Which version of nRF Connect do you use? I tested with v. 1.1.1.

    Update 30.05.17: When the data length is less than 20 bytes, nRF Connect (Android) and nRF Connect (PC) send a "Write request with authorization" instead of a "Prepare Write Request". If you try to transmit less data than 20 bytes, set a breakpoint at BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST, you will see that "Write request with authorization" is being used.

    When setting the properties of a characteristic, there is no way to set "queued write", what can to be set is "write" or " write without response". When setting "write", it looks like "write request" will be used for data shorter than 20 bytes, and "queued writes" will be used for data longer than 20 bytes.

    However, if you implement your own client, you can use "queued writes" for data shorter than 20 bytes as well.

  • Thanks for responding. I am also using 1.1.1 and it does work if I write more than 20 bytes. So, it would appear that if I want to support writing a block of data between 1 and N bytes, I would have to implement two characteristics - one variable length 'normal' characteristic to handle writes that do not exceed 20 bytes and a second variable length 'long' characteristic for writes that exceed 20 bytes (implemented as a queued write). Would that be correct or is there some way to create a single 'long' characteristic that can handle writes of between 1 and N > 20 bytes?

    I do have another question if that's OK. In the queued write example, you set the buffer size to 500 bytes but set BLE_QWRS_MAX_LONG_CHAR_LEN = NRF_BLE_QWRS_MAX_RCV_SIZE = 128. This suggests that the max value for N is 128. I was under the impression this could be 512 or 510 depending on whether or not the 'long' characteristic is defined as having variable length. Can you tell me the maximum number of bytes I can write as part of a queued write and if there is any timeout condition that may have to be adjusted to support writing the maximum number of bytes?

    Thanks for your help.

  • OK, I have discovered by testing that the maximum allowed length for a long variable length characteristic is indeed 510 bytes, and that the minimum corresponding buffer size I can map to this characteristic without triggering a fatal error on every write is 686 bytes. This is 6 bytes less than what is given by the formula ceil(510*23/17)+2 = 692 (which I discovered as part of a different thread pertaining to the nRF51822 with SoftDevice S110 version 7.1). So, my question final question is the following. Does the above formula also apply to the nRF52832 running SoftDevice S132 version 3.0.0? Thanks for the help.

  • FormerMember
    0 FormerMember in reply to FormerMember

    I have answered the first part of your question by updating my answer.

Related