Dropped packets

RE: Dropped packets

mchartier — Mon, 16 Dec 2019 15:23:20 GMT

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

RE: Dropped packets

Kenneth — Mon, 16 Dec 2019 09:05:22 GMT

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

RE: Dropped packets

mchartier — Thu, 12 Dec 2019 17:25:32 GMT

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.

RE: Dropped packets

Kenneth — Wed, 11 Dec 2019 20:38:08 GMT

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

RE: Dropped packets

mchartier — Tue, 10 Dec 2019 19:13:56 GMT

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.

RE: Dropped packets

mchartier — Tue, 10 Dec 2019 17:55:44 GMT

This ticket seems relevant to my issue. I read at least 20 related tickets and some are contradictory, so please let me know if the referenced ticket is misleading in any way. I based my code changes on this ticket.

I looked through all possible error codes for sd_ble_gatts_hvx() and the most likely error is NRF_ERROR_RESOURCES. I only send 13B packets at 50hz so fundamentally this is not a throughput issue. Instead I believe the central may have a problem keeping up and/or there is a radio issue. Those are events I cannot control, but I do need to design the system so it can handle a certain number of packet retransmissions causing delays causing packets to accumulate in the Tx queue. So I need a "good" sized queue and I need to make sure the SD is configured properly so it can drain the queue when the radio link is good. This means sending multiple packets per connection interval until the queue is drained. How can I make sure my configuration is correct. I have no visibility into the number of retransmissions or the queue size or the number of packets sent per connection interval. All I can do is configure the SD in a way that I think is optimal for my application. So to that end here is the configuration I plan to try. Please let me know if you see any way to improve on this:

nRF is acting as peripheral with just 1 BLE link to the central
Maximum notification packet size 49B, typical packet size is 13B
Notifications are sent at 50hz
LFCLK accuracy = 100ppm
GAP data length = 49+4
GAP event length = 100
GATT max MTU size = 49
Tx queue size is determined by the SD. Should I override this somehow?
Connection interval 30ms
Slave latency 0
Connection supervision timeout 3s
Connection event extension = enabled

The last setting is unclear to me. If I do not explicitly enable connection event extension, does that mean the SD will only send 1 packet per connection interval? And what is the downside (or tradeoff) when this setting is enabled?

The queue size chosen by the SD seems to be limited by the length of the connection interval. I would double that queue size if I could so the system could tolerate longer periods of time when packet retransmits are required.

But whatever the queue size, I need to define the application behavior when the queue becomes full. Several tickets suggest waiting for the system to transmit one packet from the queue before trying to send any new packets. However I don't see how this changes anything. My application will just keep calling sd_ble_gatts_hvx() and simply count the errors. Implementing a busy flag just complicates the logic without any obvious benefit, or am I missing something.

RE: Dropped packets

Kenneth — Thu, 05 Dec 2019 21:31:51 GMT

Not saying Apple have an issue, just trying to say that an lfclk out of of tolerance (either to due to hardware or timing issue in scheduler) would give the same symptoms "dropped packets".

Best regards,

Kenneth

RE: Dropped packets

mchartier — Thu, 05 Dec 2019 17:58:40 GMT

Ahh, now I remember that setting. LF accuracy is indeed set to 20ppm. I assume there would be a power penalty if I increase the setting to 100ppm. Should I assume the clock accuracy of the iPhone is not published and not well known? I am no expert on these oscillators but I know they only cost $0.20 for a good one so it just seems unlikely Apple would use a cheaper part with worse accuracy.

RE: Dropped packets

Kenneth — Thu, 05 Dec 2019 16:39:40 GMT

In your project you should find a NRF_SDH_CLOCK_LF_ACCURACY value. This is typically used in nrf_sdh_enable_request() when calling sd_softdevice_enable(). You can set this value to something larger than the tolerance of the physical crystal you have in your design, by setting it larger you can compensate for a peer that may be slightly out of it's own tolerance spec. For instance if you have 20ppm in your design you likely have used NRF_CLOCK_LF_ACCURACY_20_PPM, however you may set it to NRF_CLOCK_LF_ACCURACY_100_PPM.

Kenneth

RE: Dropped packets

mchartier — Thu, 05 Dec 2019 15:06:55 GMT

Not sure how I would change the LF clock tolerance. Is that a setting in the SD or would I need to replace the physical crystal?

RE: Dropped packets

Kenneth — Thu, 05 Dec 2019 13:41:48 GMT

I have seen in the past that sometimes the peer device have an lfclk which exceed their reported tolerance, to compensate for this it is possible to set the tolerance of the local clock to be a bit relaxed. So it may be worth trying +- 100ppm just to see if that may be help here (though I doubt).

Kenneth

RE: Dropped packets

mchartier — Wed, 04 Dec 2019 23:39:09 GMT

#define NRFX_CLOCK_CONFIG_LF_SRC 1

LF clock tolerance is +- 20ppm

Yes iOS 13 is a bugger of a release which gives us an easy out with the customer in the short term.

RE: Dropped packets

Kenneth — Wed, 04 Dec 2019 18:45:50 GMT

Hi,

If this is with an iOS device, then check out:
https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf

Also in general, it may be worth asking the customer to install the latest iOS version (even Beta), they are fixing issues constantly, and I have seen that Beta have solved issues in the past. Though, a sniffer log would be very helpful to prove one way or the other.

What lfclk source and tolerance have you configured here?

Kenneth

RE: Dropped packets

mchartier — Wed, 04 Dec 2019 15:14:34 GMT

I should have clarified I was sending notifications with sd_ble_gatts_hvx() so your guess was spot on.

The problem was never seen in ~9mo of development. We only see this in one customer device so we will try to get that device and see if we can dupe the problem in the lab. My hunch is that iOS is nack'ing enough to cause an overflow in the Tx buffer, although I don't understand why iOS would consistently send nacks for one peripheral and not the other when they are both sending notifications at the same rate. The nRF application will just ignore the error and proceed with the next notification. I can add some error counters and capture the return code from sd_ble_gatts_hvx() and find a way to send that information over to the central so it can be logged.

Should I be looking closer at the BLE connection parameters? I know the peripheral must negotiate with central to get the preferred connection parameters, but how would I know if the Central is not cooperating?

RE: Dropped packets

Kenneth — Wed, 04 Dec 2019 09:22:00 GMT

All communication in BLE should be reliable, does sd_ble_gatts_hvx() return any error code in this situation? Do you have any on-air sniffer log that show the issue?

Kenneth