Dropped packets

[mchartier]

Test Setup:

SD 6.1.0

SDK 15.2.0

Peripheral:  nRF52840

Central: iOS 13.1

Central is connected to two peripherals, each peripheral is sending 50 pkt/s, each packet has 13 bytes of payload. Connection interval is 30ms. Over hundreds of hours of testing this setup works great and we see no packet loss, however we now have one device which fails *sometimes*. We have three recordings where one peripheral is normal but the other peripheral shows  this pattern:

pkt-1, pkt-2, DROP, pkt-4, pkt-5, DROP, pkt-7, pkt-8, ...

We detect the drops by checking a continuity counter (cc) in the packet on the central device. The cc is an 8-bit value which increments for each packet sent by the peripheral. On the central we check each packet to make sure the cc value is equal to the previous packet +1.  

So.. any thoughts how to debug this? 

My first thought was to check error counters in the Nordic SD but could not find any nack counters or retransmit counters. iOS gives you nothing. 

[mchartier]

Another data point:  I enabled debug logging in the GATT module and I see this in the logs:

 nrf_ble_gatt: Updating data length to 53 on connection 0x0.
 nrf_ble_gatt: Data length updated to 53 on connection 0x0.
 nrf_ble_gatt: max_rx_octets: 53
 nrf_ble_gatt: max_tx_octets: 53
 nrf_ble_gatt: max_rx_time: 2120
 nrf_ble_gatt: max_tx_time: 2120

The data length is correct. However max_tx_time is 2120us which seems very short given that I set NRF_SDH_BLE_GAP_EVENT_LENGTH to 100 which equates to 125ms. By my calculations 2120 is almost exactly the time required to transmit 4 packets with a payload of 49B.  

49B Tx Time = 8 * (49 + 17) / 10^6 = 528us

2120us / 528us = 4.01

Therefore my code changes are not having the desired affect. In fact increasing the GAP event length to 200 had no effect on the max_tx_time. 

[Kenneth]

Have in mind that max_rx_time and max_tx_time is just how long a single packet can be transmitted/received, so these large numbers typically apply to coded phy where the on-air packet is much longer in time due to slower on-air data rate. These two values do not impact throughput.

You can find throughput numbers here depending on configuration:
https://infocenter.nordicsemi.com/topic/sds_s140/SDS/s1xx/ble_data_throughput/ble_data_throughput.html?cp=4_5_3_0_16 

Using maximum ATT MTU size (247bytes)/LL payload size(251bytes) is my best recommendation to increase throughput.

Best regards,
Kenneth

[mchartier]

I made all the code changes I listed above and I confirmed the queue size has increased and the SD is able to send multiple packets per connection interval. 

I will also consider your suggestion to increase ATT MTU size to 247 bytes. Is there any downside to making this change? I imagine it will require more memory but that will not be a problem. 

Side note: The SD always reports a single packet was transmitted when I receive the event BLE_GATTS_EVT_HVN_TX_COMPLETE. In my case it seems the TX_COMPLETE event is sent for every single packet even when the SD is able to transmit multiple packets in the connection interval. 

[Kenneth]

There should be no downside to increasing MTU and LL size no. If you are only able to send 1 packet/interval, a sniffer log may be helpful:

Download:
https://www.nordicsemi.com/Software-and-tools/Development-Tools/nRF-Sniffer-for-Bluetooth-LE

Documentation:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_sniffer_ble%2FUG%2Fsniffer_ble%2Fintro.html

Then we can find if the peripheral have set the MD (more data) bit when transmitting packets, and if indeed iOS ignore it.

Best regards,
Kenneth

[mchartier]

There is nothing more I can do for this issue except wait for another occurrence and then analyze the logs. Please close this ticket.