Unable to read long characteristics when MTU is 23 bytes using nRF Connect Android APP

[RRWC]

Information about my setup:

I'm working on a product using nRF52832 with SDK 17.0.2 and Softdevice s132 7.2.0. It is a custom board.

The default configuration (peripheral side - nRF52832) negotiate BLE connection parameters as follows:

• MTU: 230 Bytes
• Data Lenght: 234 Bytes (NRF_SDH_BLE_GAP_DATA_LENGTH)
• NRF_SDH_BLE_GAP_EVENT_LENGTH: 10 (1.25 ms units)
• PHY: 2 MB
• MIN_CONN_INTERVAL: 150 ms
• MAX_CONN_INTERVAL: 180 ms
• SLAVE_LATENCY: 5
• CONN_SUP_TIMEOUT: 4000 ms

The device (nRF52832) have a custom service with multiple characteristics. Some of these characteristics can have up to 512 bytes of data available to read. The Nordic nRF Connect Android APP is used for test purposes and the reading of characteristics is performed using the "down arrow" read button available in the APP next to all characteristics configured as "read enabled". A few recent smartphone models from different brands were used in tests, all with the same results.

Normal Behavior:

When the device connects to a smartphone, the parameter negotiation ends smoothly within the specified parameters. All readable characteristics in the custom service can be read with no problems. 

Problem situation:

Multiple tests are performed to confirm proper device operation in various use cases. One of the tests requires renegotiating some of the above parameters after the connection is stablished.

The problem starts when the MTU is changed to 23 (regardless of other parameters). The negotiation of the MTU itself finishes successfully. After that, only characteristics with few bytes of data can be read. If you try to read longer characteristics a GATT 133 error is reported in the nRF Connect side and the data is not received. The nRF52832 appears to believe the data has been sent and updates the data for new readings.

The connection is not lost after GATT 133 error, it remains stable and other characteristics can be read. If the characteristics are larger than a certain amount of bytes a new GATT 133 error is reported, otherwise the data is correctly received by nRF Connect.

Is there some configuration or something that could be preventing more than a few bytes of data from being read from a characteristic when the smartphone negotiates a 23 bytes MTU?

Is there any way (or any reading mode of BLE characteristics) to automatically confirm that data has been received by the smartphone on the nRF52832? Some of the data must be erased from the device after the smartphone reads it, it would be nice to have confirmation of data delivery in the lower layers of the BLE/SDK to avoid this kind of management in my code.

Thank you in advance for your help.

[Hung Bui]

Hi RRWC, 

Could you try to capture a sniffer trace ? Which phones did you use to test ? Could you use NRF Connect app to test ? 
Error 133 is a generic error , so it doesn't tell much. 

Please note that the MTU can only be updated once. If by default it's 23 and changed to anything else, you can't change it back to 23. 
I did a quick test here and it seems that it worked fine with the ATT_MTU of 23. (NRF_SDH_BLE_GATT_MAX_MTU_SIZE)

You can see that the read blob was successful and the length was 23 bytes on each packet. 

I attached here my quick example with a characteristic with 100 bytes length initial value. Please replace the ble_nus.c of the ble_app_uart example. If you do a read from the phone on the TX characteristic it should give you 100 bytes array. 

Fullscreen 0602.ble_nus.c Download

/**
 * Copyright (c) 2012 - 2021, Nordic Semiconductor ASA
 *
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without modification,
 * are permitted provided that the following conditions are met:
 *
 * 1. Redistributions of source code must retain the above copyright notice, this
 *    list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form, except as embedded into a Nordic
 *    Semiconductor ASA integrated circuit in a product or a software update for
 *    such product, must reproduce the above copyright notice, this list of
 *    conditions and the following disclaimer in the documentation and/or other
 *    materials provided with the distribution.
 *
 * 3. Neither the name of Nordic Semiconductor ASA nor the names of its
 *    contributors may be used to endorse or promote products derived from this
 *    software without specific prior written permission.
 *
 * 4. This software, with or without modification, must only be used with a
 *    Nordic Semiconductor ASA integrated circuit.
 *
 * 5. Any software provided in binary form under this license must not be reverse
 *    engineered, decompiled, modified and/or disassembled.
 *
 * THIS SOFTWARE IS PROVIDED BY NORDIC SEMICONDUCTOR ASA "AS IS" AND ANY EXPRESS
 * OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED. IN NO EVENT SHALL NORDIC SEMICONDUCTOR ASA OR CONTRIBUTORS BE
 * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
 * GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 *
 */
#include "sdk_common.h"
#if NRF_MODULE_ENABLED(BLE_NUS)
#include "ble.h"
#include "ble_nus.h"
#include "ble_srv_common.h"

#define NRF_LOG_MODULE_NAME ble_nus
#if BLE_NUS_CONFIG_LOG_ENABLED
#define NRF_LOG_LEVEL       BLE_NUS_CONFIG_LOG_LEVEL
#define NRF_LOG_INFO_COLOR  BLE_NUS_CONFIG_INFO_COLOR
#define NRF_LOG_DEBUG_COLOR BLE_NUS_CONFIG_DEBUG_COLOR
#else // BLE_NUS_CONFIG_LOG_ENABLED
#define NRF_LOG_LEVEL       0
#endif // BLE_NUS_CONFIG_LOG_ENABLED
#include "nrf_log.h"
NRF_LOG_MODULE_REGISTER();


#define BLE_UUID_NUS_TX_CHARACTERISTIC 0x0003               /**< The UUID of the TX Characteristic. */
#define BLE_UUID_NUS_RX_CHARACTERISTIC 0x0002               /**< The UUID of the RX Characteristic. */

#define BLE_NUS_MAX_RX_CHAR_LEN        BLE_NUS_MAX_DATA_LEN /**< Maximum length of the RX Characteristic (in bytes). */
#define BLE_NUS_MAX_TX_CHAR_LEN        BLE_NUS_MAX_DATA_LEN /**< Maximum length of the TX Characteristic (in bytes). */

#define NUS_BASE_UUID                  {{0x9E, 0xCA, 0xDC, 0x24, 0x0E, 0xE5, 0xA9, 0xE0, 0x93, 0xF3, 0xA3, 0xB5, 0x00, 0x00, 0x40, 0x6E}} /**< Used vendor specific UUID. */


/**@brief Function for handling the @ref BLE_GAP_EVT_CONNECTED event from the SoftDevice.
 *
 * @param[in] p_nus     Nordic UART Service structure.
 * @param[in] p_ble_evt Pointer to the event received from BLE stack.
 */
static void on_connect(ble_nus_t * p_nus, ble_evt_t const * p_ble_evt)
{
    ret_code_t                 err_code;
    ble_nus_evt_t              evt;
    ble_gatts_value_t          gatts_val;
    uint8_t                    cccd_value[2];
    ble_nus_client_context_t * p_client = NULL;

    err_code = blcm_link_ctx_get(p_nus->p_link_ctx_storage,
                                 p_ble_evt->evt.gap_evt.conn_handle,
                                 (void *) &p_client);
    if (err_code != NRF_SUCCESS)
    {
        NRF_LOG_ERROR("Link context for 0x%02X connection handle could not be fetched.",
                      p_ble_evt->evt.gap_evt.conn_handle);
    }

    /* Check the hosts CCCD value to inform of readiness to send data using the RX characteristic */
    memset(&gatts_val, 0, sizeof(ble_gatts_value_t));
    gatts_val.p_value = cccd_value;
    gatts_val.len     = sizeof(cccd_value);
    gatts_val.offset  = 0;

    err_code = sd_ble_gatts_value_get(p_ble_evt->evt.gap_evt.conn_handle,
                                      p_nus->tx_handles.cccd_handle,
                                      &gatts_val);

    if ((err_code == NRF_SUCCESS)     &&
        (p_nus->data_handler != NULL) &&
        ble_srv_is_notification_enabled(gatts_val.p_value))
    {
        if (p_client != NULL)
        {
            p_client->is_notification_enabled = true;
        }

        memset(&evt, 0, sizeof(ble_nus_evt_t));
        evt.type        = BLE_NUS_EVT_COMM_STARTED;
        evt.p_nus       = p_nus;
        evt.conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
        evt.p_link_ctx  = p_client;

        p_nus->data_handler(&evt);
    }
}


/**@brief Function for handling the @ref BLE_GATTS_EVT_WRITE event from the SoftDevice.
 *
 * @param[in] p_nus     Nordic UART Service structure.
 * @param[in] p_ble_evt Pointer to the event received from BLE stack.
 */
static void on_write(ble_nus_t * p_nus, ble_evt_t const * p_ble_evt)
{
    ret_code_t                    err_code;
    ble_nus_evt_t                 evt;
    ble_nus_client_context_t    * p_client;
    ble_gatts_evt_write_t const * p_evt_write = &p_ble_evt->evt.gatts_evt.params.write;

    err_code = blcm_link_ctx_get(p_nus->p_link_ctx_storage,
                                 p_ble_evt->evt.gatts_evt.conn_handle,
                                 (void *) &p_client);
    if (err_code != NRF_SUCCESS)
    {
        NRF_LOG_ERROR("Link context for 0x%02X connection handle could not be fetched.",
                      p_ble_evt->evt.gatts_evt.conn_handle);
    }

    memset(&evt, 0, sizeof(ble_nus_evt_t));
    evt.p_nus       = p_nus;
    evt.conn_handle = p_ble_evt->evt.gatts_evt.conn_handle;
    evt.p_link_ctx  = p_client;

    if ((p_evt_write->handle == p_nus->tx_handles.cccd_handle) &&
        (p_evt_write->len == 2))
    {
        if (p_client != NULL)
        {
            if (ble_srv_is_notification_enabled(p_evt_write->data))
            {
                p_client->is_notification_enabled = true;
                evt.type                          = BLE_NUS_EVT_COMM_STARTED;
            }
            else
            {
                p_client->is_notification_enabled = false;
                evt.type                          = BLE_NUS_EVT_COMM_STOPPED;
            }

            if (p_nus->data_handler != NULL)
            {
                p_nus->data_handler(&evt);
            }

        }
    }
    else if ((p_evt_write->handle == p_nus->rx_handles.value_handle) &&
             (p_nus->data_handler != NULL))
    {
        evt.type                  = BLE_NUS_EVT_RX_DATA;
        evt.params.rx_data.p_data = p_evt_write->data;
        evt.params.rx_data.length = p_evt_write->len;

        p_nus->data_handler(&evt);
    }
    else
    {
        // Do Nothing. This event is not relevant for this service.
    }
}


/**@brief Function for handling the @ref BLE_GATTS_EVT_HVN_TX_COMPLETE event from the SoftDevice.
 *
 * @param[in] p_nus     Nordic UART Service structure.
 * @param[in] p_ble_evt Pointer to the event received from BLE stack.
 */
static void on_hvx_tx_complete(ble_nus_t * p_nus, ble_evt_t const * p_ble_evt)
{
    ret_code_t                 err_code;
    ble_nus_evt_t              evt;
    ble_nus_client_context_t * p_client;

    err_code = blcm_link_ctx_get(p_nus->p_link_ctx_storage,
                                 p_ble_evt->evt.gatts_evt.conn_handle,
                                 (void *) &p_client);
    if (err_code != NRF_SUCCESS)
    {
        NRF_LOG_ERROR("Link context for 0x%02X connection handle could not be fetched.",
                      p_ble_evt->evt.gatts_evt.conn_handle);
        return;
    }

    if ((p_client->is_notification_enabled) && (p_nus->data_handler != NULL))
    {
        memset(&evt, 0, sizeof(ble_nus_evt_t));
        evt.type        = BLE_NUS_EVT_TX_RDY;
        evt.p_nus       = p_nus;
        evt.conn_handle = p_ble_evt->evt.gatts_evt.conn_handle;
        evt.p_link_ctx  = p_client;

        p_nus->data_handler(&evt);
    }
}


void ble_nus_on_ble_evt(ble_evt_t const * p_ble_evt, void * p_context)
{
    if ((p_context == NULL) || (p_ble_evt == NULL))
    {
        return;
    }

    ble_nus_t * p_nus = (ble_nus_t *)p_context;

    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_CONNECTED:
            on_connect(p_nus, p_ble_evt);
            break;

        case BLE_GATTS_EVT_WRITE:
            on_write(p_nus, p_ble_evt);
            break;

        case BLE_GATTS_EVT_HVN_TX_COMPLETE:
            on_hvx_tx_complete(p_nus, p_ble_evt);
            break;

        default:
            // No implementation needed.
            break;
    }
}


uint32_t ble_nus_init(ble_nus_t * p_nus, ble_nus_init_t const * p_nus_init)
{
    ret_code_t            err_code;
    ble_uuid_t            ble_uuid;
    ble_uuid128_t         nus_base_uuid = NUS_BASE_UUID;
    ble_add_char_params_t add_char_params;
    static uint8_t test[100];
    VERIFY_PARAM_NOT_NULL(p_nus);
    VERIFY_PARAM_NOT_NULL(p_nus_init);
    for (uint8_t i=0;i<100;i++) {
      if (i%10==0) test[i]=52; else test[i]=50;
    }
    
    // Initialize the service structure.
    p_nus->data_handler = p_nus_init->data_handler;

    /**@snippet [Adding proprietary Service to the SoftDevice] */
    // Add a custom base UUID.
    err_code = sd_ble_uuid_vs_add(&nus_base_uuid, &p_nus->uuid_type);
    VERIFY_SUCCESS(err_code);

    ble_uuid.type = p_nus->uuid_type;
    ble_uuid.uuid = BLE_UUID_NUS_SERVICE;

    // Add the service.
    err_code = sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY,
                                        &ble_uuid,
                                        &p_nus->service_handle);
    /**@snippet [Adding proprietary Service to the SoftDevice] */
    VERIFY_SUCCESS(err_code);

    // Add the RX Characteristic.
    memset(&add_char_params, 0, sizeof(add_char_params));
    add_char_params.uuid                     = BLE_UUID_NUS_RX_CHARACTERISTIC;
    add_char_params.uuid_type                = p_nus->uuid_type;
    add_char_params.max_len                  = 200;//BLE_NUS_MAX_RX_CHAR_LEN;
    add_char_params.init_len                 = 100;//sizeof(uint8_t);

    add_char_params.char_props.write         = 1;
    add_char_params.char_props.write_wo_resp = 1;

    add_char_params.read_access  = SEC_OPEN;
    add_char_params.write_access = SEC_OPEN;

    err_code = characteristic_add(p_nus->service_handle, &add_char_params, &p_nus->rx_handles);
    if (err_code != NRF_SUCCESS)
    {
        return err_code;
    }

    // Add the TX Characteristic.
    /**@snippet [Adding proprietary characteristic to the SoftDevice] */
    memset(&add_char_params, 0, sizeof(add_char_params));
    add_char_params.uuid              = BLE_UUID_NUS_TX_CHARACTERISTIC;
    add_char_params.uuid_type         = p_nus->uuid_type;
    add_char_params.max_len           = 200;//BLE_NUS_MAX_TX_CHAR_LEN;
    add_char_params.init_len          = 100;//sizeof(uint8_t);
    add_char_params.is_var_len        = true;
    add_char_params.char_props.notify = 1;
    add_char_params.char_props.read= 1;
        add_char_params.p_init_value = test;
    add_char_params.is_value_user= 1; 

    add_char_params.is_var_len               = true;

    add_char_params.read_access       = SEC_OPEN;
    add_char_params.write_access      = SEC_OPEN;
    add_char_params.cccd_write_access = SEC_OPEN;

    return characteristic_add(p_nus->service_handle, &add_char_params, &p_nus->tx_handles);
    /**@snippet [Adding proprietary characteristic to the SoftDevice] */
}


uint32_t ble_nus_data_send(ble_nus_t * p_nus,
                           uint8_t   * p_data,
                           uint16_t  * p_length,
                           uint16_t    conn_handle)
{
    ret_code_t                 err_code;
    ble_gatts_hvx_params_t     hvx_params;
    ble_nus_client_context_t * p_client;

    VERIFY_PARAM_NOT_NULL(p_nus);

    err_code = blcm_link_ctx_get(p_nus->p_link_ctx_storage, conn_handle, (void *) &p_client);
    VERIFY_SUCCESS(err_code);

    if ((conn_handle == BLE_CONN_HANDLE_INVALID) || (p_client == NULL))
    {
        return NRF_ERROR_NOT_FOUND;
    }

    if (!p_client->is_notification_enabled)
    {
        return NRF_ERROR_INVALID_STATE;
    }

    if (*p_length > BLE_NUS_MAX_DATA_LEN)
    {
        return NRF_ERROR_INVALID_PARAM;
    }

    memset(&hvx_params, 0, sizeof(hvx_params));

    hvx_params.handle = p_nus->tx_handles.value_handle;
    hvx_params.p_data = p_data;
    hvx_params.p_len  = p_length;
    hvx_params.type   = BLE_GATT_HVX_NOTIFICATION;

    return sd_ble_gatts_hvx(conn_handle, &hvx_params);
}


#endif // NRF_MODULE_ENABLED(BLE_NUS)

Regarding your question about how the application aware that the peer has read the characteristic. You can implement read with authorization. Please see here. You'll need to use is_defered_read when declare the characteristic. 

[RRWC]

Hello Hung Bui, thank you for your reply.

I am in fact using NRF Connect app to test. All tests reported above where performed using the NRF Connect. This makes it easier to identify if the problem is on the nRF52832 side or on our end user APP.

I performed a sniffer trace as requested. I'll walk through the normal behavior and the problem case described earlier using screenshots from the sniffer trace and from nRF Connect.

Normal Behavior

After the connection everything runs smoothly. The screenshots bellow show normal operation with parameters automatically negotiated between nRF52832 and a Samsung Galaxy S21 (same results with a Samsung Galaxy M51 and an Asus Zenfone Max pro M1)

Connection establishment and parameter negotiation

Below are screenshots of all parameters that have been automatically negotiated right after the connection was established.

[Slave] Connection parameter update request. Parameters accordingly to the desired parameters informed in the first post.

[Slave] Request data length change to 234 bytes

[Master] Reply data length update request

[Slave] Request MTU change to 230 bytes

[Master] Reply MTU update request

[Master] Data length update request. Not sure why the master decides to renegotiate data length, but I believe this is not related to the problem as everything continues to work normally after this.

[Slave] Request PHY change to 2 MB

[Master] 2 MB PHY accepted

[Slave] Reply data length update requested by the master

[Master] Reply parameter update request

[Slave] Parameter negotiation request. Not sure why it happens again here, but the parameters are set as desired.

[Master] Reply parameter negotiation

[Master] Connection parameters accepted

Data transmission with MTU 230 bytes

Shortly after the above negotiations ended I read some characteristics.

[Master] Read 7 byte characteristic

[Slave] Send 7 byte characteristic data:

[Master] Read 512 byte characteristic

[Slave] Send successfully 512 byte characteristic

nRF Connect side:

In these nRF Connect logs you can see almost all the steps shown from the sniffer side so far. Everything works.

Changing MTU to 23 bytes

Now a command is issued from nRF connect to change the MTU to 23 bytes. This is done using the "..." menu in the upper right corner. With this command, the master will request an MTU of 23 bytes.

Note that previously the slave was responsible for requesting the MTU change to 230 bytes. You said the MTU can only be changed once per connection, but I believe each side can request the change once per connection (at least it seems that way considering the behavior, I really don't remember exactly what the BLE spec says about it right now) . In fact, after requesting a new MTU using nRF Connect you will not be able to request it again on the same connection.

[Slave] Reply MTU request from master

[Master] New data Length request. This is not a command directly issued via nRF Connect. Probably the Android BLE stack decided that 27 bytes make smore sense with a 23 byte MTU.

[Slaves] Reply data length request

Reading characteristics with 23 bytes MTU and problem

After the above negotiation, characteristics a few bytes long can be read normally, but longer characteristics cannot.

[Master] Read 7 byte characteristic

[Slave] Successfully send 7 bytes characteristic data

[Master] Try 512 bytes characteristic read

[Slave] 512 bytes characteristic data is partially send. Data never displayed in master.

[Slave] Last data packet error detail

The connection remains active and it is even possible to read the data of the characteristics, although if there is too much data the error will be repeated.

Error in nRF Connect side

Below you can see the steps that led to the error in the nRF Connect log. After the first error, new readings are performed, with success in the case of short features and with error in the case of long features.

As far as I know the BLE stack should automatically split the data and send it even using the 23 byte MTU and 27 byte data length. However, for some reason, only characteristics containing only few bytes of data are being transferred. Can you help me understand if there is something not configured correctly or where is the problem?

Regarding the read with authorization question, currently the device is notified when the reading starts. However, using the above example, I have no information about the failure to deliver the data. Is there an proper callback to confirm that all data registered in the characteristic were successfully delivered?

Thank you in advance,

Ricardo

[Hung Bui]

Hi RRWC, 

Thanks for the detailed information. Could you please send us the sniffer trace files ? 

I did a quick test here and found a similar issue. So that if the MTU was 23 bytes at the initial phase and the phone doesn't request a change to larger one (247 in my case) the read worked fine. It's what I observed in my first reply where I give an example of 100 bytes read and with the NRF_SDH_BLE_GATT_MAX_MTU_SIZE set to 23. 

In your case you set NRF_SDH_BLE_GATT_MAX_MTU_SIZE to 230 I assume. And then in nRF Connect app you request an ATT MTU of 23. 

The problem of this is that the ATT_MTU request should only be sent once in a connection. In your case, the phone actually request it twice. First when connected (automatically request to 230 bytes)  and then you in the app request a 2nd one with 23 bytes.

This violate the Bluetooth Spec: 

In the code for NRF52 you can find the same requirement : 

You can't call sd_ble_gattc_exchange_mtu_request() twice in a connection. 

So from my point of view it's a wrong implementation in the phone's BLE stack that it allows att exchange to be requested twice. 
Could you describe your use case on why you want to change the ATT MTU back to 23 bytes ? 

Please be aware that ATT_MTU can only be exchanged once, but the Data length extension can be changed multiple times. If you want to limit the size of the on air packets you can change the data length instead of the ATT_MTU. 

Another note is that Data length usually = ATT_MTU + 4 . This is why you see 27 bytes data length when you request 23 byte ATT MTU. It's due to the 4 bytes overhead on link layer. 

[RRWC]

Hello Hung Bui,

I'm sending the sniffer trace as requested. This file contains pre-connection advertising and all data shown in the screenshots (same trace).

BLE_23MTU_read_fail.pcapng

Regarding the MTU exchange, I'm still a bit confused. The specification says that the client should only send the MTU request once per connection. However, it was the nRF52832 that actively requested the MTU change on the first change (to 230 Bytes). Wouldn't that allow the phone to request to change the MTU once during the connection even if the device already requested it once? Just for the record, actually in my app the phone is the Client (as usual the data is on the peripheral, the nRF52832). The use of the terms Client and Server in this case leaves room for ambiguous interpretations in my opinion. I would appreciate it if you confirm that the MTU should only be exchanged once regardless of the side starting the MTU update request, although this is just to better understand the specification. I don't intend to change it more than once in my application, I will explain more of my test case below.

Regarding my test case, the ideal condition is when the MTU is 230 bytes and Data length is 234 bytes. This is what my device will request. However, these values ​​also depend on what the phone and its BLE stack decide. What I really want to test is if data transfer, internal data update and overall device operation are OK in case of 23 byte MTU and 27 byte data length being selected by the Central. I have no need nor intention to explicitly change the MTU to 23 bytes, but I would like to check compatibility with phones selecting this MTU even when the peripheral configuration allows a higher MTU.

Extending a little bit this explanation, this is a final product test (not a prototype). We have more freedom and control over the nRF52832 side so we prefer to fix bugs in the firmware side even if they are caused by wrong implementation in the other devices stack to ensure wide compatibility. However, our tests use the firmware as close to the final version as possible (exactly the same for most tests). We want to test that the final firmware version will correctly handle the 23 byte MTU request from the master with the current configuration and not to change the configuration on the nRF52832 side to test and send a different configuration to the field. Also, if the phone is able to send this request once even after the device changed the MTU before we'll look for a way to keep things working even in that scenario, if possible.

Thank you in advance,

Ricardo.

[Hung Bui]

Hi Ricardo, 

You are right. The requirement is that MTU exchange is once per client. Meaning there could be up to 2 MTU exchanges, initialize by the client on each side.

However, there is another requirement from the spec: 

This is also reflected in our API: 

In this case, the phone replied to the nRF52 with Server RX 230 in the earlier exchange and then on the 2nd exchange it request with client RX = 23 which is violating the spec. 

From what I can see in the trace, the softdevice still operate normally even with this violation that it still reply with correct read response (fragmented and then re-assembled) : 

My understanding is that the phone had an issue interpret the response and gave GATT error. 

I understand your concern that if you have no control over the peer there could be a chance that this issue may rise and you want  to have a way to check if the peer have received the data correctly. As far as I know there isn't a way to have a confirmation of a read. You can have a confirmation when you do a write (write request or write with response) but not with a read. 

What you can do is either make a server on the phone and write data from the nRF52 to the server on the phone instead of a read. Or if you want to keep it as a read, you can have an extra characteristic on the nRF52 that the phone can write a receipt when it managed to read. It can be a hash of the data of the read for example.