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

Using GATT Module in IoT UDP example

I want to change DLE/MTU in udp (IoT) example in order to test throughput with max mtu, is it possible?

The udp example does not contain nrf_ble_gap library, is it possible to just simply add it and try to test max throughput using max mtu?

Parents
  • Hello,

    The IoT folder in SDK root is not maintained (actually it was removed from the latest SDKs).

    The reason for this is that it was not much used, and hence never finished. 

    I suggest that you look into other implementations than the IP over BLE. 

    That said, I am not sure how you change the MTU in these examples. 

     

    The udp example does not contain nrf_ble_gap library

     Where have you seen it being used?

    For MTU changes, I would look into how the SDK\examples\ble_peripheral\ble_app_uart uses nrf_ble_gatt_att_mtu_periph_set() in main.c, and how the service also uses the callback value from gatt_evt_handler() to set the new MTU in the service (not actually setting anything with regards to the softdevice, but as an application layer protection to prevent it to send too long packets).

    That being said, I wouldn't recommend using the IoT libraries in commercial products. If so, make sure to test it properly.

    Best regards,

    Edvin

Reply
  • Hello,

    The IoT folder in SDK root is not maintained (actually it was removed from the latest SDKs).

    The reason for this is that it was not much used, and hence never finished. 

    I suggest that you look into other implementations than the IP over BLE. 

    That said, I am not sure how you change the MTU in these examples. 

     

    The udp example does not contain nrf_ble_gap library

     Where have you seen it being used?

    For MTU changes, I would look into how the SDK\examples\ble_peripheral\ble_app_uart uses nrf_ble_gatt_att_mtu_periph_set() in main.c, and how the service also uses the callback value from gatt_evt_handler() to set the new MTU in the service (not actually setting anything with regards to the softdevice, but as an application layer protection to prevent it to send too long packets).

    That being said, I wouldn't recommend using the IoT libraries in commercial products. If so, make sure to test it properly.

    Best regards,

    Edvin

Children
  • Thank you for your reply.

    My question had a mistake, I was referring to nrf_ble_gatt.c. (GATT module)

    Goal: To evaluate ipv6 over ble throughput with different configurations (ATT_MTU, Data_length, Connection Interval, and Gap Event Length) similar to ATT_MTU Throughput Example but I want to do that in experimental iot udp examples (UDP Examples).

    My setup:

    • nRF5 SDK v16.0
    • I have udp server example running on nrf52840DK, and raspberrypi 3 b+, as border router.
    • I am able to communicate to the udp server from my raspberrypi as well as from other linux pc's in my local network.

    I made following changes in sdk_config.h

    #define NRF_SDH_BLE_GAP_DATA_LENGTH 251 
    #define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247
    
    #define NRF_BLE_GATT_ENABLED 1

    And following changes in ipv6_medium_ble.c inside ipv6_medium_init(...) function.

    //right after ble_stack_init();
    
    err_code = nrf_ble_gatt_init(&m_gatt, gatt_evt_handler);
    if (err_code != NRF_SUCCESS)
        {
            return err_code;
        }
        
    err_code = nrf_ble_gatt_att_mtu_periph_set(&m_gatt, NRF_SDH_BLE_GATT_MAX_MTU_SIZE);
    if (err_code != NRF_SUCCESS)
        {
            return err_code;
        }
        

    But after testing I see that att_mtu remains unchanged, its still only 27 bytes.  

  • The MTU is negotiated on each link, and it will always start at a default value, 27/23/20 bytes, depending on how much of the headers you are counting. You have 20 bytes of BLE payload. 

    First after the BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST the changes are negotiated, and at the event BLE_GAP_EVT_DATA_LENGTH_UPDATE it is actually set. 

    After connection one of the devices will propose a new MTU, let us say the central suggest 251 bytes. Then the other device (say peripheral) says that it can do 180 bytes. That means that they agree on 180. They will always use the minimum that both support. If your RPi only supports 27, then there is nothing you can do. 

    Do you get the BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST or BLE_GAP_EVT_DATA_LENGTH_UPDATE events?

  • Thank you for your suggestions. Solved!!

    Actually, what I noticed right after posting the question was, my raspberry pi was not 3b+, but 3B actually.

    So no question of having Data length extension feature. 

    I quickly moved to RPI 3b+, but now, my connection dropped after a minute.

    I tried RPI 4B as well, but connection dropped, even with un modified udp example, i.e without any changes in data length in sdk_config.h , connection dropped.

    After trying different raspbian verions, the problem still persisted, where as connection was still stable with my Raspberrypi 3B (Bluetooth spec 4.1) but data length was ofcourse not extending.

    Then I added following code and connection became stable as well as DLE worked:

    #define NRF_SDH_BLE_GAP_DATA_LENGTH 251 
    #define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247
    
    #define NRF_BLE_GATT_ENABLED 1

    //right after ble_stack_init();
    
    err_code = nrf_ble_gatt_init(&m_gatt, gatt_evt_handler);
    if (err_code != NRF_SUCCESS)
        {
            return err_code;
        }
        
    err_code = nrf_ble_gatt_att_mtu_periph_set(&m_gatt, NRF_SDH_BLE_GATT_MAX_MTU_SIZE);
    if (err_code != NRF_SUCCESS)
        {
            return err_code;
        }
        

            case BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST:
            {
                NRF_LOG_DEBUG("BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST");
                ret_code_t err_code;
                err_code = sd_ble_gap_data_length_update(p_ble_evt->evt.gap_evt.conn_handle, NULL, NULL);
                if(err_code == NRF_SUCCESS){
                  NRF_LOG_DEBUG("data_length_Resp_sent_success");
                                            }
                break;
            }
            case BLE_GAP_EVT_DATA_LENGTH_UPDATE:
            {
                NRF_LOG_DEBUG("BLE_GAP_EVT_DATA_LENGTH_UPDATE");
    
                break;
            }

Related