Hi Nordic team,
I would like to provide an overview of our system:
- Interval: 10ms, slave latency: 0, supertimeout: 4S
- Sampling and sending packets: 160 bytes (including a 2-byte counter) from nRF to PC.
- 128 packets/s
- Under favorable and ideal conditions, throughput is ensured, and timing on the receiving end is good (using PC timestamp to check packets).
- Under poor connectivity conditions or when the device is placed far from the PC, the throughput decreases, leading to packet loss (sampling process is faster than sending to the PC). We use the counter to determine the number of lost samples and PC timestamp to calculate the sample rate.
- The sampling process is independent of the BLE notify function, so it is not blocking.
We placed the device in a microwave and closed the door to simulate poor connectivity. Since the supertimeout is 4S, we can leave the device in there for <4S without losing the connection.
We use k_msgq to store sampled data and send it to the PC through the bt_gatt_notify_cb function. We've discovered that this function is blocking, and the data remains in the network core's FIFO until it's successfully sent.
As you can see in the figure below, poor connectivity appears at counter 6852. PC receives counter 6852 at Timestamp 40684.445 PC receives counter 6854 at 40687.262, with a difference of 2.817S from the previous counter, and these are 2 consecutive counters. This issue leads to inaccuracies in calculations. We've noticed that during this time, the FIFO in the network core holds packets from 6854 to 6872 until a connection is reestablished before continuing transmission. Meanwhile, our device continues to sample. Specifically, at the timestamp 40687.332, we received counter 7548, resulting in the loss of 676 packets.
The major issue we encountered is the more than 2-second difference in the receiving time of 2 consecutive counters. Is it possible to flush the FIFO in the network core? If not, can we attach a timestamp or elapsed time to the packet?
I'm not a native English speaker, so please bear with my expression.
Thanks,
