Migration from SDK13.1 to SDK15.2 resulted in a data waveform not flowing smoothly.

[mzarling]

My nRF52832 firmware application transmits data to iPad which converts it into a flowing waveform. The waveform flowed smoothly when SDK13.1 was used. I migrated the firmware to SDK15.2 and now the waveform increments in steps rather than flowing smoothly. The min and max connection intervals have not changed. I noticed with SDK13.1 there was no entry for NRF_SDH_BLE_GAP_EVENT_LENGTH in sdk_config.h, so I assumed it used the default of 3 assigned to BLE_GAP_EVENT_LENGTH_DEFAULT. However in SDK15.2 there is an entry for NRF_SDH_BLE_GAP_EVENT_LENGTH and it was set to 6, so I changed it to 3 to match the original when in SDK13.1. This did not help much.

In SDK15.2 the nrf_ble_gatt.c logs are:

Peer on connection 0x0 requested a data length of 251 bytes.
Updating data length to 27 on connection 0x0.
Data length updated to 27 on connection 0x0.
max_rx_octets: 27
max_tx_octets: 27
max_rx_time: 1364
max_tx_time: 1364
on_ble_event: got BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST
Peer on connection 0x0 requested an ATT MTU of 293 bytes.
Updating ATT MTU to 23 bytes (desired: 23) on connection 0x0.

In SDK13.1 the nrf_ble_gatt.c logs are:

Peer on connection 0x0 requested a data length of 251 bytes.
Updating data length to 27 bytes on connection 0x0.
Data length updated to 27 on connection 0x0.
max_rx_octets: 27
max_tx_octets: 27
max_rx_time: 328
max_tx_time: 328
on_ble_event: got BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST
Peer on connection 0x0 requested an ATT MTU of 185 bytes.
Updating ATT MTU to 23 bytes (desired: 23) on connection 0x0.

The glaring differences are the max_rx_time and max_tx_time. In SDK15.2, I can get those values reduced by decreasing NRF_SDH_BLE_GAP_EVENT_LENGTH value to lowest allowable of 2, which reduces the max_rx_time and max_tx_time, but they are still more than twice the value used in SDK13.1. It did slightly help the waveform though.

What other parameters should I be looking at to get my waveform flowing smoothly again? The max rx and tx times are set to BLE_GAP_DATA_LENGTH_AUTO in both SDKs. Are there other parameters that may be different between the 2 SDKs?

[Vidar Berg]

"You asked "is it possible that the SDs tx output buffer is being emptied when the 5 packets are sent on the third connection event?" Can you explain this more? What are the implications? How can I determine if the tx buffer was emptied?"

I meant that maybe the softdevice manages to send all notifications in one event, so that there no packets to send on the subsequent connection event. Notification packets get queued in the Softdevice when you call sd_ble_gatts_hvx() while waiting for the next connection event to arrive. And the stack will trigger the BLE_GATTS_EVT_HVN_TX_COMPLETE event once the packet(s) have been acked by the client (message sequence chart). 

You can use the BLE_GATTS_EVT_HVN_TX_COMPLETE event to monitor queue usage, please refer to the message sequence chart I linked to above. 

[mzarling]

You are right. The tx buffer is emptied and then the next connection event has nothing to send. Something is clearly different between using SDK13.1 and SDK15.2. With the same event length of 3, same max_tx_time of 328, same min/max connection interval of 30mS, using SDK13.1 results in 3 packets sent per connection event, but using SDK15.2 results in 5 packets sent per connection event. How can I mimic/force fewer packets per connection event to ensure that every connection event has data to send? Every time there is no data to send in a connection event, there will be a hiccup in the flow of my waveforms at the central device.

[mzarling]

Hi Vidar. Sorry for the late reply, but do you have anything to suggest regarding my last reply? Thank you.