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

low peripheral gatt data transmit throughput with s132-5.0

i took the original sdk 14.2.0 s132-5.0 ble-uart nus-service example for reference measurements to send data from a 52832 to an android device running nrf uart v2.0

to provide a measurable data stream i do not get data from the hw uart, but from a 5 ms periodic timer tick in the main loop which stuffs up to 20 bytes or less into ble_nus_string_send ... at this time it's irrelevant where the data comes from and how much it is ... it can never be more than 20 bytes every 5 ms which would be a max of 4 k bytes / sec

i encounter NRF_ERROR_RESOURCES errors when the data is consistently 20 bytes for prolonged 5 ms periods

in case i get an NRF_ERROR_RESOURCES error i suspend the 5 ms tick ble_nus_string_send until i get a BLE_GATTS_EVT_HVN_TX_COMPLETE event

i have to say that i changed the following as suggested in some forum posts

sdk_config.h : #define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 23

void gatt_init(void) : err_code = nrf_ble_gatt_att_mtu_periph_set (&m_gatt, BLE_GATT_ATT_MTU_DEFAULT) ;

no other changes besides the data feed from the 5 ms source in the main loop have been made

the same modifications to the sdk 12.2.0 ble-uart example handles this data amount without any data or buffer overflow errors

why is the sdk 14.2.0 s132 flavor slower than the sdk 12.2.0 one

i have not really found any easy means to change any gatt based internal data queue configurations or similar

what's wrong with feeding the ble_nus_string_send at a 5 ms period

to keep feeding any available data in the BLE_GATTS_EVT_HVN_TX_COMPLETE event versus figuring out if this is still going within the main loop seems a bit complicated for a simple test case and restarting the ble_nus_string_send within main in case that the event driven feed ended

there is a lot of talk about data throughput and large amounts of data along with plenty of simple appearing code snippets, but in reality gluing those code snippets into the right place and make it work is a totally different story

for the fact of the existence of all those talks and the total lack of a working performance example, other than the one lonely token ble-uart example which can not really be used for any performance eval, i have to say it's a very uninhabitable desert out there

speaking ironically for my self, we are not all ble geniuses and staring at a wireshark trace without any explanation of what all the acronyms mean, it's still a very foreign language and the one and only token youtube video on how to turn on and configure an ancient version of nrf-sniffer is not too much help either

sorry for the maybe hard sounding words, but please try to imagine yourself in the shoes of potential not too experienced potential new ble customers, we're already at your doorsteps, please don't chase us away

yes, i'm working now for almost 2 month reading and reading and setting up tools which do not cost $ 5 k upwards a seat and have it all working and the ble-uart nus example works, but now that the real eval of performance starts it seems another mountain range is between success and failure

thanks for reading what i felt as being important for being a potential new customer

cheers Klaus

p.s. i added the android data overflow drop screenshot

added wireshark trace nrf52831-slow-varsz.pcapng which i took with variable line length of 3 - 97 including \r\n at 100 ms periods ... this trace is taken from my modified uart ble example with my Ble.cpp/h class, but the org uart-ble example with only the test send feed produces the same err signature

android-data-reception.png

nrf52832-slow-varsz.pcapng

addendum

after more testing i simplified my testing strategy

max length test data string, being truncated by various tests "123456789_ABCDEFGHI_JKLMNOPQR_STUVWXYZ0_123456789_abcdefghi_jklmnopqr_stuvwxyz0_ 123456789_987654321_0zyxwvuts"

for repeat-ability i'm sending a fixed length stream of data every 500 ms for all tests

those bursts are split up in up to 20 bytes being put into ble_nus_string_send at 5ms intervals

on a 51822 sdk 12.2.0 softdevice based project i can send up to 6 consecutive 20 byte data packages before an overflow condition happens ... 20 bytes * 6 = 120 bytes takes 5 ms * 6 = 30 ms

reducing the 500 ms stream data generation time to 45 ms starts some random overflows ... 1000 ms / 45 = 22 pkgs / sec with a total of 120 bytes payload results in 2640 bytes / sec with minor random data loss

wireshark trace with 105 (120) byte strings and no overflow 51822-12.2-105-5ms.pcapng

on a 52832 sdk 14.2.0 softdevice based project i can send up to 4 consecutive 20 byte data packages before an overflow condition happens

wireshark trace with 80 byte strings and no overflow 52832-14.2-80-5ms.pcapng

wireshark trace with 85 byte strings and overflow 52832-14.2-85-5ms.pcapng

wireshark trace with 105 byte strings and overflow 52832-14.2-105-5ms.pcapng

what would need to be changed on the sdk 14.2.0 based project config to also achieve the same 6 or more consecutive 20 byte packets without the overflow condition

are there any que size differences between sdk 12.2.0 and 14.2.20 or simply asked ... what are the differences causing the lower data bandwidth with the sdk 14.2.0

  • What throughput do you get with 12.2 versus 14.2? Do you have the same connection interval?

    Have you tried to increase the event length? NRF_SDH_BLE_GAP_EVENT_LENGTH

    Have you enabled connection event length extension?

    static void conn_evt_len_ext_set(bool status)
    {
        ret_code_t err_code;
        ble_opt_t  opt;
    
        memset(&opt, 0x00, sizeof(opt));
        opt.common_opt.conn_evt_ext.enable = status ? 1 : 0;
    
        err_code = sd_ble_opt_set(BLE_COMMON_OPT_CONN_EVT_EXT, &opt);
        APP_ERROR_CHECK(err_code);
    }
    
  • sdk version 12.2 gets about 3 x throughput based upon the observation of data overflow at up to 100 bytes at 30 ms periods and version 14.2 experiences this overflow already at up to 100 bytes at the slower 100 ms periods

    the ble nus example code has not been changed as well as any parameter #define values or any sdk_config.h values ... the sdk_config.h in each test case is the one from the matching example version

    the connection interval settings on both versions are equal 20 min, 75 max and i have not changed them

    the following code snippet i placed in both ble_evt_handler(s) display a min and max of 39 upon connection

    switch (p_ble_evt->header.evt_id) {
    case BLE_GAP_EVT_CONNECTED :
      .........
      ble_gap_conn_params_t parm = p_ble_evt->evt.gap_evt.params.connected.conn_params ;
      uint min = parm.min_conn_interval ;
      uint max = parm.max_conn_interval ;
      PRINT (" ble : Conn min %d max %d \r\n", min, max) ;
    }
    break ;	// BLE_GAP_EVT_CONNECTED
    

    i have increased, as suggested, the #define NRF_SDH_BLE_GAP_EVENT_LENGTH value from it's initial value of 3 in some steps up to 15 without any really noticeable improvements

    thank you for the conn_evt_len_ext_set code snippet, but where is it supposed to be placed and what value is the status parameter supposed to be or where would it come from

    the android device for testing is a nexus 7 2013 running android 6.0.1 marshmallow

    since both ble nus examples are being used in an out of the box fashion with the same minor test mods applied one would expect an equal behavior or even a slightly better one from the 14.2 sdk

    it's hard, for a not too ble experienced person, to make freely changes not really knowing of their impacts

    so far i have made many successful changes in implementing my own code, which is not ble related, like adc, uart, timer, intrs and application related classes and more, but in an other project and it's progressing fine

    i just need to button up this ble performance issue and the ble related part of the app should be solved

    sorry, but i'm at a beginner level when it comes to ble.

  • What kind of performance tests do you actually want to do? Are you aware of this?

    You mention sniffer traces, do you have these? Could you upload them so I can take a look at them?

    Anyways, if you want to want to measure throughput in the ble_app_uart example the first step is to have some way of measuring it, so that you have a quantified value, not just observations.

    You can call conn_evt_len_ext_set() from main(), like in ble_app_att_mtu_throughput example.

    Status should be true if you want to enable CLE, false if you want to disable CLE.

  • to the question performance i would like to mention that the "Experimental: ATT_MTU Throughput Example" is a really nice idea, however i hope my needs for now are of easier nature like having an everyday android (nexus 7 2013) device supporting ble 4.0 communicating with the pca10040

    maybe all the suggested tests with 2 pca10040 talking to each other or the larger mtu along with the data length extension are i believe options for later revs after ble 4.0, like ble 4.2 and 5.0 ... i could be wrong, sorry

    i did not have a chance to repeat the wireshark traces ... no time today, but i will do it ... it's quite an elaborate setup, switching all the different firmware projects along with the right softdevices, saving the data and verifying the integrity and i'm not a wireshark expert ... worked last with it when it was called ethereal on tcp/ip pkgs i believe

    with respect to the connection interval, i believe it's the central device (nexus 7) which mostly dictates the setup ... also the initial setup data is the same for both ble nus example versions 12.2 vs 14.2

    measurements and observations are some stretchable terms one can be measured in time units and or data over time ... i used the term observation for the following undisturbed data amount over time

    i send the following data lines, one every defined time period = 100 ms

    1\r\n
    12\r\n
    123\r\n
    1234\r\n
    12345\r\n
    ... fill in the missing data lines
    123456789_ABCDEFGHI_JKLMNOPQR_STUVWXYZ0_123456789_abcdefghi_jklmnopqr_stuvwxyz0_1234567\r\n
    123456789_ABCDEFGHI_JKLMNOPQR_STUVWXYZ0_123456789_abcdefghi_jklmnopqr_stuvwxyz0_12345678\r\n
    123456789_ABCDEFGHI_JKLMNOPQR_STUVWXYZ0_123456789_abcdefghi_jklmnopqr_stuvwxyz0_123456789\r\n
    123456789_ABCDEFGHI_JKLMNOPQR_STUVWXYZ0_123456789_abcdefghi_jklmnopqr_stuvwxyz0_12345678\r\n
    ... fill in the missing data lines
    124\r\n
    123\r\n
    12\r\n
    1\r\n
    123\r\n
    1234\r\n
    ... fill in the data missing lines
    and on and on
    

    the result of this test is that as soon as the line lengths exceed about a total of 80 chars i observe (realtive measure) some data drop ... i would call this kind of setup a high level real world test setup

    now the comparison measurement on a sdk 12.2 setup exhibits those data drops at a line repeat time of 30 ms which relates to a data throughput range of 3 times of the 14.2 setup

    the question would be now, would this qualify as a quantified value ?

    the fact from my point of view, again i could be wrong, is that both ble nus examples are as much as possible out of the box and unaltered ... the only change is that a timer feeds the nus data string of up to 20 bytes at a defined period ... the global ble configuration seems to be the same as well

    i did not write either ble nus examples, nor am i an expert on the internals and details of the sdk api and softdevices ... all i provide is a measurable repeatable determined data flow into the ble nus example

    so how could i effectively debug the differences of the code i didn't write

    all i'm really doing is to feed the ble_nus_string_send function my data in a timed and measurable way and i do this the same way in both examples and this goes after 10 line of code directly into the soft device

    the overall setup and other callback and glue is part of the example code from nordic

    yes, i'm not using keil or other approved tools, my setup is in a managed project setup in eclipse

    i can zip up the projects and send them to you if desired

    i can also provide the wireshark traces once i repeat the testing in a couple of days

    sorry for being such a pest ... all i really want to do right now is to receive and send nus data (preferably fast) and add my app code and ship it

  • Please send me two sniffer traces first, and we will take it from there.

Related