Throughput ATT_MTU

We are using nrf52832 soc for our product development and using that we are trying to increase the throughput of our device using the information from the following forum:
Novel Bits throughput guide 
In this forum it states that the Maximum GATT MTU SIZE possible is 247 bytes in which 244 bytes of data is the actual payload size and if the data is greater than the limit, then it will split into multiple packets. So we tried to send more that 247 bytes of data just to check how the data split in multiple packet is working. We tried to sent 256 bytes of data and we were able to get 255 bytes of data without any splitting, which is more than 247 bytes. So we are wondering what is the Maximum GATT MTU SIZE possible in nrf52832 soc. 
We also looked into the throughput example provided by the nordic (ble_app_att_mtu) and in that MTU size is set to 247 and data length is set to 251 which is less that what we are able to send from nrf52832 to phone, is there any possible explanation for this?

Parents
  • Hi

    2. I'm not sure I understand what you're asking here. If the ATT MTU changes but the data length stays the same you won't increase the throughput much I'm afraid, as the data length should also be increased according to what you increase the ATT MTU with. The 2000 bytes over 2 seconds would equate to ~1 kB per second (8 kbits per second).

    3. Once connected, the central will be in charge of deciding the PHY that is used, but you can set the preferred PHY in the BLE_GAP_EVT_PHY_UPDATE_REQUEST event to BLE_GAP_PHY_2MBPS instead of BLE_GAP_PHY_AUTO as .rx_phys and .tx_phys like below (this must be added to/edited in the ble_evt_handler() function of your main.c file:

            case BLE_GAP_EVT_PHY_UPDATE_REQUEST:
            {
                NRF_LOG_DEBUG("PHY update request.");
                ble_gap_phys_t const phys =
                {
                    .rx_phys = BLE_GAP_PHY_2MBPS,
                    .tx_phys = BLE_GAP_PHY_2MBPS,
                };
                err_code = sd_ble_gap_phy_update(p_ble_evt->evt.gap_evt.conn_handle, &phys);
                APP_ERROR_CHECK(err_code);
            } break;

    Then you need to initiate a PHY update request from the central, and as long as the central supports the 2MBPS PHY, the connection should move to the 2MBPS PHY.

    Best regards,

    Simon

Reply
  • Hi

    2. I'm not sure I understand what you're asking here. If the ATT MTU changes but the data length stays the same you won't increase the throughput much I'm afraid, as the data length should also be increased according to what you increase the ATT MTU with. The 2000 bytes over 2 seconds would equate to ~1 kB per second (8 kbits per second).

    3. Once connected, the central will be in charge of deciding the PHY that is used, but you can set the preferred PHY in the BLE_GAP_EVT_PHY_UPDATE_REQUEST event to BLE_GAP_PHY_2MBPS instead of BLE_GAP_PHY_AUTO as .rx_phys and .tx_phys like below (this must be added to/edited in the ble_evt_handler() function of your main.c file:

            case BLE_GAP_EVT_PHY_UPDATE_REQUEST:
            {
                NRF_LOG_DEBUG("PHY update request.");
                ble_gap_phys_t const phys =
                {
                    .rx_phys = BLE_GAP_PHY_2MBPS,
                    .tx_phys = BLE_GAP_PHY_2MBPS,
                };
                err_code = sd_ble_gap_phy_update(p_ble_evt->evt.gap_evt.conn_handle, &phys);
                APP_ERROR_CHECK(err_code);
            } break;

    Then you need to initiate a PHY update request from the central, and as long as the central supports the 2MBPS PHY, the connection should move to the 2MBPS PHY.

    Best regards,

    Simon

Children
  • Simonr,

    I have tested BLE 5.0 LE 1M phy and BLE LE 2M Phy

    i took 10,000 logs of 12 bytes data at 2 secs interval.

    I am able to receive the logs

    #define MIN_CONN_INTERVAL MSEC_TO_UNITS(1000, UNIT_1_25_MS) /*

    #define MAX_CONN_INTERVAL MSEC_TO_UNITS(1000, UNIT_1_25_MS) /*

    NRF_SDH_BLE_GAP_DATA_LENGTH 31/162/251

    NRF_SDH_BLE_GATT_MAX_MTU_SIZE 27/158/247

    WITH these combinations on sniffer i found:

    My issue is that why in LE 2M same data is taking more time compared to LE 1M?

Related