Event to Event offset time smaller then specs show

[Mathias]

Hi!

I'm having a little trouble with my measurements. A little situation sketch:

I'm using two nRF51822 DK's who act as peripheral and connect to a nRF51 Dongle that acts as central. The peripherals use application code that continuously changes (increments) a certain characteristic and sends notifications about that to the central. Because of that, the peripheral each send the max. number of packets per interval that the central allows to the central (in this case 3, cause this is what the newest firmware for the Dongle allows as max.), each packet containing a maximum of 20 bytes user payload of course. Both peripherals use HIGH BW configuration (both TX and RX), or in other words, the default setting.

The goal of this is to sniff the packet flow and prove that the provisioning of connection events happens according to the specs of the SoftDevice (s130 v2). According to those specs, I made some calculations. The tEEO should be 6.9 ms for both peripheral connection events because we are using HIGH BW configuration for both. So the minimal time between two events, each of another peripheral, should be 6.9 ms. This gives 6.9 + 6.9 = 13.8 ms as minimum boundary for the connection interval. This gives 15 ms as minimal connection interval. Using this interval, the situation was implemented. After both connections are established and the notifications from both peripherals are being send, the sniffer shows something like the figures below:

Now my question is: How is it that the time between the C0 and C1 event is 3.792 ms, which is far less then the theoretical minimum of 6.9 ms? The second figure is there to give a complete picture, showing that the next C0 event is indeed 15 ms away.

Thanks for your help in advance.

Gr

Mathias

[endnode]

Have you considered inaccuracy of time display by your fancy sniffer HW&SW bundle?

[Mathias]

It's roughly the same, every snif.

[endnode]

Reading it again but not sure what are all the timings in your diagrams and what are corresponding numeric values:

• Can we agree that basic connection interval of 15ms works in your case as it is delta between start events of first Master->Slave packet in each interval?
• Then timing inside interval itself between Master Tx->GAP#1->Slave Tx->GAP#2 etc. isn't cut into slots but is dynamic depending on each PDU length. BLE spec just says how long after end of received PDU should opposite side start to transmit (150us to be specific). See slides 97, 124 and 125 here. Are your Empty PDU length + GAP#1 + full Slave PDU length in contradiction with this? If so then could you write it down more clearly?

Without knowing details about your payload length simplified numbers would be:

[endnode]

3xEmpty PDU (Master->Slave) + 5xGAP (between each of 6 PDUs) + 3xFull PDU (Slave->Master) = 3x80 + 5x150 + 3x330 = 2ms meaning that final GAP between end of last PDU and start of first PDU of next connection interval should be very close to 13ms. Is it the case? Note that even some more expensive sniffers like Frontline do perform well in ~10us range but not very much below (they usually show almost precise 150us timing on gaps but then fail to be as accurate on other measurements), however still you should not get OFF by more then few hundreds of microseconds.

[Mathias]

Thanks for the input. Answering your clarification questions:

• Yes, indeed.
• Time between each PDU (Master-Slave) beginning and PDU (Slave-Master) beginning, is 230 µs. Minus 80 µs for the Master-Slave PDU duration, this gives perfect 150 µs GAP. Time between each PDU (Slave-Master) beginning and PDU (Master-Slave) beginning, is 446 µs. Minus 330 µs, this gives 116 µs, which is a bit less then 150 µs ... But all in all the time between end of last PDU and start of first PDU of next connection interval, is indeed very close to 13 ms (12.972 ms to be precise). I'm using Peryton as Sniffer software, combined with a Sabrent hardware sniffer piece.