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
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
