BLE Throughput with S112

[marklander]

Hi guys,

starting to improve my throughput with an nrf52805 and S112, i know this version does not support DLE, but it's also the one with lower footprint, I will ask you some questions because i see something that is not clear to me, I read around that there are also "issues" due to mobiles and OS, but to start I will drop here a log from the sniffer and then share other doubts.

Basically I am testing with an android device with nrf toolbox, using NUS to exchange a text file of about 70Kb to get data rate.

First of all I will drop this log...

connection_from_nrf_toolbox_to_nrf52805.pcapng

In this I cannot understand why in packet 1133 here below:

I see a connection interval of 7.5 msec ( so 6 units ) and then after some messages for discovery i get another LL_CONNECTION_UPDATE_IND, both from the master with this...

Where connection interval is set to 45 ms ( so 32 units )

What I can't understand is that I setup my sd to 24 units of interval so 30 ms, but I never see this request...

Where am I wrong?

Than I will have other doubts about data rate...i will attach here a longer long where first I send the file from nrf toolbox to embedded board and then viceversa and seems much more faster when data is sent from embedded to mobile, I just have an UART sending data to Ble via NUS.

mobile-to-nrf52-and-viceversa.pcapng

 Any help is appreaciated in my journey to a higher data rate...

Thanks

[billtsai]

Hi,

Host will decide the connection interval.

If host has new connection itnerval, the device will receive BLE_GAP_EVT_CONN_PARAM_UPDATE event.

You can add BLE_GAP_EVT_CONN_PARAM_UPDATE in ble_evt_handler and the new connection params will in p_ble_evt->evt.gap_evt.params.conn_param_update.conn_params.

If connection interval is not meet your request, you can use sd_ble_gap_conn_param_update to request host updates connection parameters.

[marklander]

Thanks billtsai , sounds clear will try! A question on connection event length which is supported by Softdevice 112, do I need to set this parameter before central connection or after it's connected i need to request an update?

And by the way in your opinion what could be a realistic data rate i can reach? From nrf toolbox I copy and paste 22.5 Kb of text in roughly 12 secs...I think I can get higher also without data extension...

Another doubt, connection event length is just used by the device activating it right? I mean i activate it on my peripheral, but this does not mean that it is used also by central, i don't see any exchange of data about this settings between devices.

[billtsai]

Just set the connection event length parameter in sdk_config.h.

You can refer to S112 spec

https://infocenter.nordicsemi.com/topic/sds_s112/SDS/s1xx/ble_data_throughput/ble_data_throughput.html?cp=5_7_0_0_16

[marklander]

Ok! I am using Rust, but i think it's correctly setted on my side ( peripheral )

Other questions:

Q1: I see from the sniffer logs that when i update the parameters of connection ( min interval, max interval , timeout and latency ) my two android mobile in the end accept parameters, but android sends a final  LL_CONNECTION_UPDATE_IND  with the final parameters decided by android and seems that I cannot go under 9 units of connection interval. Is this a typical android behaviour?

Q2: many times in the sniffer I see event counter jumping in steps of 3, is this something related to channels? Why i see that?

[billtsai]

Q1: My android phone is pixel and it can run at 7.5m sec interval. Is your phone connecting with other ble or bt device?

Q2: I'm not sure. But you can find the channel index in the packet.

[marklander]

Q1: no i am just connecting mobile as central to my board as peripheral, what I see also is that for example if I send max interval of 30 and min of 14 it seems settings the average value in the end so 22.

I will check better my config parameters anyway... I tried on an older asus zenfone with android 9 and also with a samsung a12 with android 13.

Q2: will check i was just asking if it's a normal behaviour or not.