Severe packet loss on Android 9

[mfmc]

Hello,

We are facing an issue where we are having a lot of packet loss (UART nrf52832) on two sensors connected to an Android Application (Android Pie 9.0). The tablet model that runs the application is a Galaxy Tab A (2019) Samsung T-515 (already supports BLE 5.0). Moreover that behavior does not happen on other tablet/smartphones models that supports BLE 4.2 such as the previous version Galaxy Tab A (2016) Samsung T-585.

[Kenneth]

Hi, some questions to narrow down the cause:

1- Does the issue occur when using an nRF52-DK for test? 

2- Have you verified the sensor design by running DTM and/or spectrum analyzer to check frequency accuracy?

3- Have Nordic reviewed the sensor design?

4- Do you have any on-air sniffer logs that I may look at?

It may be that the design is marginally out of spec, this could prevent performance with some peers.

Best regards,
Kenneth

[mfmc]

Hi Kennet

We don't think is an directly hardware issue since por example if we connect with sensors X,Y,Z by this order the X will have more lost packts and Z almost 0. For two sensors only the first one has severe packet loss.

We are going to get on-air sniffer logs to put here for analysis.

[mfmc]

Hi Kennet,

Th test that was made was connecting two sensors with the tablet, by subscribing two services with a frequency sample of 50Hz.
We verified that the second tracker tthat was connected didn't have packet loss.
Please check the table below with the timestamps and events that evidence the issue (for further analysis check please the on-air sniffer logs.) Attached is  also some examples of what we think that could be the issue.

Best,

Timestamp	Sniffer does not see packet/Sniffer detects CRC error	Tablet/Master requires packet retransmission
850.250		x
850.251	x
850.364	x
850.588	x	x
850.819	x
851.488		x
851.493	x
851.715	x	x
851.827	x	x
851.831		x
851.947	x	x

packet_loss_logs.pcapng

[Kenneth]

I would not say it is much packet loss here, however I do see that the More Data bit is set in the packets from the peripheral to indicate that more data is available, but that the central "ignore" the More data bit and don't fetch more packets from the peripheral in the same connection event (you can see that there is only 2 packets for every event counter, 1 from the central and 1 from the peripheral). I think this cause very low throughput.

I think what happens here is that the scheduler in the link layer of the central have not scheduled enough time to allow more than 1 packet from the peripheral before it needs to handle the second link. This will cause the first link to have poor throughput, but the second link will have higher throughput. It is not much Nordic can do about this, but you may for instance have different connection interval for the two sensors, e.g. one link have 45ms and second link 46.25ms (resolution is 1.25ms).

Best regards,
Kenneth