This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Improve communication throughput changing conn_params and ATT MTU params

Hi everybody,

I am working with an UART example with multi-link and everythink working on coded_s8. The objective is keep 20 devices connected and every peripheral send always 50 bytes of data every 100 ms. This are my connection parameters:

//Parametros de conexion
struct bt_le_conn_param m_conn_param=
{
	.interval_min=60,//70*0.625ms
	.interval_max=60,
	.timeout=500,
        .latency=0,
      
};

//Parametros de scaneo
static struct bt_le_scan_param m_scan_param=
{
        .type = BT_LE_SCAN_TYPE_ACTIVE,
        .options = BT_LE_SCAN_OPT_CODED | BT_LE_SCAN_OPT_NO_1M,
        .interval = BT_GAP_SCAN_FAST_INTERVAL,//60ms
        .window = BT_GAP_SCAN_FAST_WINDOW,//30ms
};

I follow this entry: https://devzone.nordicsemi.com/f/nordic-q-a/47330/connection-and-scan-interval-in-multilink-application

Which recommend  set interval of conn=scan interval and a shorter scan window. I whish know if is possible see the packets on a connection with a sniffer to make an strategy and play with parameters, but i thing is only for advertising, isn't it?

Later i see this entry, where explain that increase MTU size and gap data lenght https://devzone.nordicsemi.com/f/nordic-q-a/67249/connection-interval-and-througput/276129#276129

But i am not able to find these parameters on my project, could you guide me on where find that configuration??

My actually throughput isn't enought, i achieve between 200 and 400 messages/second, whereas the objective is 600 messages/second, I write to the UART of every peripheral an array of data every 100 ms with and external uart device. Never a message is lost, every message is sended but not on time desireed, so i am convinced that is a BLE paramter/configuration.

Any suggest or idea to improve the throughput is very welcome!

Really i think that configuring the parameters of the second link seems to be enought, but i don't know how.

I am working with the last version of SDK, and with nrf52840 dongle.

Thank you for the support Nordic team,

regards.

  • Hi another time,

    to summarize my proggress:

    config BT_L2CAP_TX_MTU that i put up to 120

    With the objective of send more bytes x packet.

    config BT_RX_STACK_SIZE
    

    I put up this value a little bit too.

    config BT_DATA_LEN_UPDATE
    

    To enable extended Data_len.

    config BT_CTLR_TX_BUFFER_SIZE
    

    To set the same value as BT_L2CAP_TX_MTU

    conn_interval set to number between 30-60ms.

    The objective is send 50 bytes every 100 ms for 20 devices to a central on coded_s8.

    My project is based on Uart example,

    On another words, after a timer o 100ms is trigger, an external device write on UART to the peripheral 50 bytes of data, and the periph send to central.

    Although i play with parameters changing conn interval, att_mtu_size, etc I am not able to see any changes on throughput. To measure the results i count bytes received by the central by one peripheral on a minute of connection one to one.

    could be some kconfig on stack sizes that i missed?

    Thank you, regards.

  • The maximum data throughput that I achieve is with this method is 2.66Kbps

  • Hi

    Discussing this more with my colleagues I realized that increasing MTU size has little effect on coded phy mode. The reason for this is that it takes a very long time to send packets when using coded phy (just a standard 27 byte payload will take more than 2ms on air), and if the stack was to send even longer packets there would be a high risk of having a packet affected by interference. If you send a very long payload and get bit errors caused by interference you risk losing the entire packet, which would then have to be retransmitted. 

    In other words there is little to gain by increasing the MTU when using coded phy. 

    I can do some testing on my own to figure out what the expected throughput in coded phy mode should be. 

    Best regards
    Torbjørn

  • Hi another time,

    Finally I achieve the throughput desired, I want to apologice because of the cause of the low throughput was part of my implementation, I didn't have the limitation on BLE channel, in addition i had on UART chanel. It was an absurd error but is closed and i have had learn a little more about.

    Thank you another time, regards.

  • Hi 

    Good to hear you found the issue Slight smile

    I will consider the case closed then. 

    Best regards
    Torbjørn

Related