Third peripheral sending Empty PDUs, dropping packets

[mwmccabe]

I'm experiencing the same issues as a previous poster that went unresolved: devzone.nordicsemi.com/.../

With 1 or 2 peripherals (sensors), the connection works fine. With 3, almost always at least one sensor drops a large number of packets (40%+) while the others work fine. I've captured some data using three different nRF52s and three sensors connected to one central. As you can see, some attribute information is sent multiple times before a stream of empty PDUs (presumably the dropped packets?) on the sensor dropping packets (for test 1 it's sensor d0, test 2 sensor e5 and test 3 sensor e5 -- I assure you, the sensors themselves are fine and can transmit without dropped packets when connected solo or with one other sensor.)

I've attached three separate trials I did and the pcaps for each sensor. I see there is a lot of communication and ultimately attribute handle errors in the sensor that starts dropping frames, but I'm not sure how to parse that conversation. Do the failed attribute received packets indicate an error of the central? I've seen mention (in this thread: e2e.ti.com/.../457865 ) of a LL_CHANNEL_MAP_REQ packets causing something similar? However I can't seem to capture an LL_CHANNEL_MAP_REQ packet for every sensor each time -- only the one that experiences issues.

My central is a Samsung Galaxy S2 Tablet. I've experienced the same issues with an S3. Any help would be very much appreciated!

BT 3 Sensor Data.zip

[Hung Bui]

Hi mwmccabe,

I see no problem with Test3 Sensor E5, the connection was terminated properly. Empty PDU just mean the central didn't do anything and then disconnect. I don't see the central does any write request to enable notification.

Test 2 Sensor E5, I don't see any connection, can say nothing here.

Test 1 Sensor D0, in this trace actually we can see something not normal. The central stopped sending empty PDU or at least the sniffer couldn't capture any packet from central.

LL_CHANNEL_MAP_REQ shouldn't be an issue here, the connection is fine until very long after the new channel map took effect.

From those data you provided, I don't see any issue from our side. Would suggest you to test with other centrals, suggest to test with central from other brand.

I assume you created an app that can handle multiple peripherals.

[mwmccabe]

My central is still receiving data from sensor E5 in Test 3, but losing roughly 50% of it. How can this be if there was no write request?

[Hung Bui]

How do you send data from E5 to central ? How do you check if it's "losing" ? what exactly is losing ?

[mwmccabe]

In our protocol, a "data frame" is composed of five notifications. This data frame has a frame counter which is used to determine whether or not frames are dropped. By losing I just meant dropped/never received by our software (so presumably the central as well.)

[Hung Bui]

BLE is a reliable protocol, meaning there will be no packet missing on link layer. A packet will be resend until it's acked. It could be the central application code cause the packet notification packet not processed, but we don't have control over it.

As you can see in the Test 3 E5 trace, there was no notification packet, I don't know how you can receive data (if not from read request).