Peripheral - Central Streaming Packet Loss

Question

I am using NUS to stream sensor data from a nRF5340 peripheral to a nRF5340 central device. I have an index that I'm able to use to track if any packets are missed, and at higher sensor bandwidths I'm intermittently missing a packet. This is generally to be expected (reaching a throughput limit), but I'm trying to determine where the packet is getting lost/dropped. In sniffing the traffic, I can clearly see an Empty PDU packet where the missing index packet should be. 
 Within the peripheral device, I am able to confirm that the packet of the (eventually) missing index is present and correct at the time bt_nus_send() is called. I am checking for returned errors, and none come back. 
 What could account for these missing packets if the data makes it into bt_nus_send() with no errors returned? 
 
 Thanks in advance

AHaug · Accepted Answer

Hi, 
 I see I formulated myself quite ambiguous in the Monday rush so I will reformulate my previous reply with some more details 
 AHaug said: But just as you know, BLE is not 100% lossless w.r.t package loss 
 This is not true, BLE is lossless. More specifically connections are lossless, while advertising/scanning has loss (which is what I based my previous comment on without elaborating). BLE connections are reliable and does not accept packet loss. That is, if a packet is not received after x attempts, the connection will be terminated. 
 Connections, notifications and indications are lossless. This means that packs sent in either of these 3 relations are in fact acked. 
 Apologies for the confusion! 
 The acknowledgement is that you increment a package sequence number based on the previous transmission you received from the peer so that you always knows that the previous is received when you get the next one. Then you can retransmit if the number is not as expected. This goes for all packs sent in a connection, not only notifications ( a notification is just a permission for the peripheral to send packs to a central unprompted). 
 Going back to the issue at hand: you are observing packet loss. This narrows us down to two most likely scenareos 
 
 The peripheral sensor and central are only advertising and scanning and not connected -> loss is to be expected
 
 Changing to a connection or using notifications should fix this

Something happens when queuing the data 
 
 Narrowing down the second item is a bit more complicated than the first one, but here are some thoughts nonetheless 
 
 Start by checking exactly how your sensor data is queued when bt_nus_send() is called
 
 If it is a Zephyr queue by some sort (and not as direct input into any softdevice buffers), there could be some differences in implementations that leads to the data being lost here. For example, if it is a ring buffer of some kind (not likely, but it could happen). 
 One way to check is if the call to bt_nus_send returns "non mem" or similar at any point in time

Let me know if this clarifies things for you, and once again apologies for the confusion regarding the not lossless statement 
 Kind regards, Andreas

Peripheral -> Central Streaming Packet Loss

Top Replies