nRF52840 throghput question

[Soojin]

Hi! I'm currently using

- board: nRF52840 DK

- SoftDevice v15

- ble_app_template example + midi (adding custom service and characteristic)

-----------------------------------------------------------------------------------------------------------

I want to achieve maximum throughput, and so far this is what I found out

1. Use notifications

2. Raise the NRF_SDH_BLE_GATT_MAX_MTU_SIZE to 247

3. Raise the NRF_SDH_BLE_GAP_DATA_LENGTH to 251 ( I assumed this is enabling DLE)

4. Use LE 2M PHY

5. Minimize Connection interval
- #define MIN_CONN_INTERVAL MSEC_TO_UNITS(7.5, UNIT_1_25_MS
- #define MAX_CONN_INTERVAL MSEC_TO_UNITS(7.5, UNIT_1_25_MS)

---------------------------------------------------------------------------------------------------------

1~3 worked fine. However, I have questions with 4 and 5. 

Question1.

I read that the minimum connection interval should be 7.5. However, when I tried changing the value above to 
#define MIN_CONN_INTERVAL MSEC_TO_UNITS(5, UNIT_0_625_MS) 
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(5, UNIT_0_625_MS)
I found out that this results in more better results. ( I could send more notifications in 1 second )
Why is this possible? And again, is the code written in 5 the minimum spec we can go to??

Question2.

The codes related to setting PHY are like below. With this code, when I connect to nRF Connect with my mobile phone(Galaxy S9) and read the PHY it is always set to 1MBPS. I've searched all day to change it to 2 MBPS, but just can't seem to change it. 

- p_advertising->adv_params.primary_phy     = BLE_GAP_PHY_1MBPS;

-

 

 // Initialize advertising parameters with default values.
    memset(&p_advertising->adv_params, 0, sizeof(p_advertising->adv_params));

    p_advertising->adv_params.properties.type = BLE_GAP_ADV_TYPE_CONNECTABLE_SCANNABLE_UNDIRECTED;

    // Use 1MBIT as primary phy if no phy was selected.
    if (phy_is_valid(&p_advertising->adv_modes_config.ble_adv_primary_phy))
    {
        p_advertising->adv_params.primary_phy = p_advertising->adv_modes_config.ble_adv_primary_phy;
    }
    else
    {
        p_advertising->adv_params.primary_phy = BLE_GAP_PHY_1MBPS;//here
    }

    if (p_advertising->adv_modes_config.ble_adv_extended_enabled)
    {
        // Use 1MBIT as secondary phy if no phy was selected.
        if (phy_is_valid(&p_advertising->adv_modes_config.ble_adv_primary_phy))
        {
            p_advertising->adv_params.secondary_phy = p_advertising->adv_modes_config.ble_adv_secondary_phy;
        }
        else
        {
            p_advertising->adv_params.secondary_phy = BLE_GAP_PHY_1MBPS;
        }
    }
    p_advertising->adv_params.filter_policy = BLE_GAP_ADV_FP_ANY;

- 

static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
{
    ret_code_t err_code = NRF_SUCCESS;

    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_DISCONNECTED:
            NRF_LOG_INFO("Disconnected.");
            // LED indication will be changed when advertising starts.
            break;

        case BLE_GAP_EVT_CONNECTED:
            NRF_LOG_INFO("Connected.");
            err_code = bsp_indication_set(BSP_INDICATE_CONNECTED);
            APP_ERROR_CHECK(err_code);
            m_conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
            err_code = nrf_ble_qwr_conn_handle_assign(&m_qwr, m_conn_handle);
            APP_ERROR_CHECK(err_code);
            break;

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

        case BLE_GATTC_EVT_TIMEOUT:
            // Disconnect on GATT Client timeout event.
            NRF_LOG_DEBUG("GATT Client Timeout.");
            err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gattc_evt.conn_handle,
                                             BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
            APP_ERROR_CHECK(err_code);
            break;

        case BLE_GATTS_EVT_TIMEOUT:
            // Disconnect on GATT Server timeout event.
            NRF_LOG_DEBUG("GATT Server Timeout.");
            err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gatts_evt.conn_handle,
                                             BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
            APP_ERROR_CHECK(err_code);
            break;

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

-   

static bool config_is_valid(ble_adv_modes_config_t const * const p_config)
{
    if ((p_config->ble_adv_directed_high_duty_enabled == true) &&
        (p_config->ble_adv_extended_enabled == true))
    {
        return false;
    }
#if !defined (S140)
    else if ( p_config->ble_adv_primary_phy == BLE_GAP_PHY_CODED||
              p_config->ble_adv_secondary_phy == BLE_GAP_PHY_CODED)//here
    {
        return false;
    }
#endif // !defined (S140)
    else
    {
        return true;
    }
}

------------------------------------------------------------------------------------------------------------------

Thanks for all your help. 

[Kenneth]

Hi,

You may want to check out this example in general:
https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.2/ble_sdk_app_att_mtu.html

To answer your questions:

1. #define MIN_CONN_INTERVAL MSEC_TO_UNITS(5, UNIT_0_625_MS) is not a valid value, so not sure what may be happening here (maybe it defaults to a higher value). In any case having larger intervals than 7.5ms may actually give higher throughput numbers, however you are trading interference performance vs. stable throughput. Because if you have larger intervals you may pack the packets closer together, however if you have packet loss it will need to wait until next interval before it can re-try. So even though using longer intervals can give higher throughput in ideal conditions with no packet loss, it will be lower throughput in a realistic scenario with other 2.4GHz devices in the proximity.

2. It may seem as you are mixing advertisement and connection parameters here. In this specific case you are interested in the throughput during a connection, so you should check the BLE_GAP_EVT_PHY_UPDATE event for the active data-rate. Check our message sequence chart:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s140.api.v7.2.0%2Fgroup___b_l_e___g_a_p___p_e_r_i_p_h_e_r_a_l___p_h_y___u_p_d_a_t_e.html 

Best regards,
Kenneth 

[Soojin]

Thanks! Now I got  PHY LE 2M working:)

So, now I think I changed every component.

According to one of Nordic's site, I found this chart
( https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsds_s140%2FSDS%2Fs1xx%2Fble_data_throughput%2Fble_data_throughput.html )

From here, the maximum data throughput I can get is 1327.5 Mbps.

So according to this data,  if I Set ATT MTU size to 247, LL payload size to 251, Connection interval to 50ms and use LE 2M PHY, will I be able to get the maximum throughput??

[Kenneth]

Soojin said:

So according to this data,  if I Set ATT MTU size to 247, LL payload size to 251, Connection interval to 50ms and use LE 2M PHY, will I be able to get the maximum throughput??

That will be the peak throughput yes with no packet loss. You may also check out this slightly old thread, but should still be valid:
https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/throughput-and-long-range-demo 

[Soojin]

Thanks Kenneth! Loads of help. 
Have a great day.