Hi there,
Currently developing a producting using two nRF52833 boards one as peripheral and one as central:
- 125kbs coded phy (S8)
- 40 byte MTU
- using extended advertising
- notifications from peripheral at 20Hz ( 40 bytes each)
- central reads characteristic from peripheral at 2Hz(4 bytes)
- tried multiple connection intervals from 7.5ms to 50ms
All data packets being notified and read include timestamps used to generate a synchonised clock on the central device and we timestamp when the notify packets at received in the notify characteristic callback and extract the peripheral timestamp from the data to compare with the central timestamp. When printing the local (central) and remote (peripheral) timestamps in the notify callback we noticed that periodically there would be a 50ms increase in time between packet arrivals on central as seen below:
all packet timestamps on peripheral are almost exactly 50ms and are very consistent.
This graph shows the time between notify packets arriving at the central device at 20Hz and the expected interval between each packet is therefore 50ms but periodically this leads to an increase up to 100ms and downto 10ms before returnign back to 50ms. we have also determined that in this process, no packets are lost. we have tried changing the connection interval between 7.5ms and 50ms with different combinations of minimum and maximum but to no effect. same with MTU size and rate of notifications and reads. we have also verified that our timestamping and timer synchonisation is correct.
additionally when the clocks for these devices are synchonised we compare the packet latency by subtracting peripheral send time from central receive time and it results in a saw tooth latency pattern when the extpected packet latency with the two board beside eachother would be a relatively straight line. all timestamps are done when the notify packet arrives on central and when the notify packet is sent on peripheral. the indidual clocks of each are very consistent and the only variation begins to appear when timestamping ble packets.
our current hypothesis is that there could be some kind of buffering occuring in the bluetooth stack between sending and receiving ble packets which might result in this behaviour but we are wondering if there could be any information which you could assist us with in determining the root of this odd latency pattern.
