slow ble uart on sdk14.2.0 s132 52832 device

Question

i have 2 setups, one on a pca10040 running sdk 14.2.0 s132 and the other one on a pca10028 clone running sdk12.3.0 s130 with a 51822_xxaa mpu 
 the ble_uart examples from both sdks got the following equal modifications 
 replaced uart code with my own (isr support) along with my own queue-ing classes 
 getting the tx data from my tx fifo and sticking it into the ble_nus_string_send funct is at a 5 ms period handled in main with a max payload of 20 bytes 
 my firmware queues (tx) up strings to a nexus 7 at a 30 ms period on the 51822 and at a 100 ms period on the 52832 ... yes, the 52832 can not handle a 30 ms data stream period 
 the periodic data strings start with a length of 1 incremented by one up to a max of 90 chars followed by a decrement by one, and again ... this provides a nice pyramid shape data scroll and any misses are visually easy to spot 
 the same kind of pyramid data is also sent by the nexus 7 to the ble device ... the max speed seems determined by the capabilities of the nexus 7 and maxes out at 100 ms 
 the 51822 ble_nus_string_send appears to exhibit err_code returns of NRF_ERROR_BUSY and BLE_ERROR_NO_TX_PACKETS, in which case i repeat the previous data on the next 5 ms ble_nus_string_send period and everything seems fine ... i can live with some data errors on long test lines 
 the slow problem child seems to be the 52832 s132 based device where the ble_nus_string_send funct returns either NRF_ERROR_BUSY or unknown error 0x13 
 why do i not get a BLE_ERROR_NO_TX_PACKETS and instead this to me unknown err 0x13 which appears to be some like missing resources or similar 
 both projects are literally almost the same, except where the s132 vs s130 dictate differences 
 what's wrong with the, should be faster, cortex-m4 52832 setups 
 one note on the side : 
 why is there, this to me significant, code difference in the ble_nus_string_send funct 
 52832
hvx_params.handle = p_nus->tx_handles.value_handle ; 
 51822
hvx_params.handle = p_nus->rx_handles.value_handle; 
 what is it now ... tx or rx ... ble_nus_string_send woudd imply tx to me 
 any help on the slow s132 based 52832 setup would be highly appreciated 
 cheers Klaus

efiLabs · Accepted Answer

thanks to Petter Myhre : 
 your last suggestion of increasing hvn_tx_queue_size to a larger number worked as in the question related to send speed below 
 devzone.nordicsemi.com/.../ 
 i used the code as suggested below with the exception of setting it to 20 instead of 4 
 devzone.nordicsemi.com/.../ 
 here is my code in ble_stack_init 
 ret_code_t err_code ;

err_code = nrf_sdh_enable_request () ;
APP_ERROR_CHECK (err_code) ;

	// Configure the BLE stack using the default settings.
	// Fetch the start address of the application RAM.
uint32_t ram_start = 0 ;
err_code = nrf_sdh_ble_default_cfg_set (APP_BLE_CONN_CFG_TAG, &ram_start) ;
APP_ERROR_CHECK (err_code) ;

	// Max Packets Per Connection Event
ble_cfg_t ble_cfg ;
::memset (&ble_cfg, 0, sizeof ble_cfg) ;
ble_cfg.conn_cfg.conn_cfg_tag = CONN_CFG_TAG ;
ble_cfg.conn_cfg.params.gatts_conn_cfg.hvn_tx_queue_size = 20 ;
err_code = sd_ble_cfg_set (BLE_CONN_CFG_GATTS, &ble_cfg, ram_start) ;
APP_ERROR_CHECK (err_code) ;

	// Enable BLE stack.
err_code = nrf_sdh_ble_enable (&ram_start) ;
APP_ERROR_CHECK (err_code) ;

	// Register a handler for BLE events.
NRF_SDH_BLE_OBSERVER (m_ble_observer, APP_BLE_OBSERVER_PRIO, ::Ble_evt_handler, NULL) ;
 
 the inserted code is under the "// Max Packets Per Connection Event" comment 
 i also added the following line in add_config.h 
 #define NRF_SDH_BLE_GAP_EVENT_LENGTH 30
 
 the data send throughput in ble_nus_string_send -> sd_ble_gatts_hvx
is now 120 byte strings in 20 byte chunks at a 45 ms period ... 120 * 22 = 2640 bytes / sec