Sniffing min max connection interval with nRF Sniffer

[Tim]

Hello,

I'm new to sniffing BLE. I'd like to determine the min and max connection interval and other connection parameters (MTU, slave latency, supervisory timeout, etc.) of a peripheral. I don't have access to the firmware. I have Wireshark+nRF Sniffer for BLE 3.0.0 installed and running my my Mac (10.14.6). I can see advertising, connection requests, etc. I've attached a screen capture. Where do I look to find these connection parameters?

Many thanks,

Tim

[Tim]

Ongoing thanks Bjørn. Correct, an iOS app (central), which we have developed, connects to 2 peripherals. We first used Simblee BLE modules, now switching to BL652. On each peripheral, a sensor is connected to a GPIO pin. We use GPIOTE to watch for sensor event (digital HiToLo). GPIOTE_IRQHandler() is called and app sends message to central via ble_nus_data_send(...) (NUS). iOS app notes time of arrival of message (CBPeripheral method didUpdateValueForCharacteristic). Then the second peripheral does the same when its sensor goes HiToLo. The iOS app now has arrival time of message from first peripheral and same for second peripheral and calculates the difference to find the time between events.

For testing, I use a 2-channel function generator and connect channel 1 to the GPIO pin on the first peripheral, channel 2 to the same on the second peripheral. I configure the function generator to pulse channels 1 and 2 at a specific offset (say, 4.35 seconds) and watch the times that the iOS apps sees upon receipt of the messages from peripherals. (I actually apply a bit more logic by determining the time for a message to go roundtrip, then divide that by 2 to get roughly the time for the message to go one way, then use that to adjust the iOS message arrival time.)

I realize that there are many possibilities for latency and latency variation. With Simblee-based boards, I measured roughly 10 ms accuracy. With BL652 boards, I'm seeing around 20 ms. I will do more testing and measurements and provide some helpful data in the coming days.

Our plan is to implement this solution for synchronizing the clocks on multiple peripherals:

https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/wireless-timer-synchronization-among-nrf5-devices

In the meantime, would like to tune code to provide the best accuracy given current implementation.

Many thanks for guidance, suggestions.

Tim

[bjorn-spockeli]

Hi Tim, 

Since a BLE central will communicate with each peer in sequentially, i.e. first peer 1, then peer 2, peer 3 etc, you will always see a fixed time difference between the reception of packets from different peers. This will be different for each peripheral pair, depending on how far the respective connection events are scheduled by the 

You also do not know when the GPIO event occured relative to the connection event, so if you call ble_nus_data_send() right after a connection event or just before a connection event will greatly affect the time it takes from the GPIO event occcuring and the packet being received by the central. 

Lastly, just looking at the reception time does not take into account packet loss or re-transmissions. You will at least need to add some logic to detect and compensate this in some way. 

So my suggestion, which you are already looking at, would be to synchronize the clock of the peripherals and then timestamp the GPIO events and compare the timestamps and not the reception time. 

So if your goal at this stage is to synchronize the two peripherals as far as possible without synching the internal timers, then you can look at lowering the connection interval and possibly look at optimizing the the interrupt handling of the GPIO event, i.e. minimize the time from the GPIO interrupt to  sd_ble_gatts_hvx() being called. 

Is current consumption a priority? If not then you can use the Constant latency mode, which ensures that the wakeup latency is kept at a minimum, see Sub power modes. 

Best regards

Bjørn

[Tim]

Thanks Bjørn. Yes, your understanding is correct. For now, I need to synchronize two peripherals as far as possible without syncing internal timers. We do plan to implement internal clock syncing as presented in this blog post.

I'm seeing very little latency between GPIO interrupt and call to sd_ble_gatts_hvx(). About 0.091551ms. I'm seeing quite a variation in time between call to sd_ble_gatts_hvx() and SoftDevice calling on_hvx_tx_complete(). Range is from 34 to 84 ms. Is this variation due to packet loss, re-transmission? Or connection interval/window? It would be helpful if I could understand the variation and account for it.

Power consumption is not critical. Our peripherals run on two AA batteries. They are used for a couple hours at a time, usually a few times a week.

The central is an iOS device so I don't have any control or access to low level BLE.

Lastly, as we look to a solution for synchronizing internal peripheral clocks, would you recommend the blog post I link to above? All we need is 10ms accuracy between two peripherals. Wondering if the blog post solution is overkill and we could achieve our 10ms requirement with something simpler.

I appreciate your replies, Bjørn. Learning a lot, which is helpful.

Tim

[bjorn-spockeli]

Hi Tim, 

Tim said:

I'm seeing very little latency between GPIO interrupt and call to sd_ble_gatts_hvx(). About 0.091551ms. I'm seeing quite a variation in time between call to sd_ble_gatts_hvx() and SoftDevice calling on_hvx_tx_complete(). Range is from 34 to 84 ms. Is this variation due to packet loss, re-transmission? Or connection interval/window? It would be helpful if I could understand the variation and account for it.

Yes, retransmissions due to packets being dropped may be the cause for the delay that is larger than the connection interval, i.e. 30ms. In order to minimize the time between calling sd_ble_gatts_hvx and the packet going on air my suggestion would be to lower the connection interval to its lowest setting, i.e. 7.5ms.

You could also use use the 2Mbps Phy, which will shorten the time it takes for the RADIO to transmit all the bytes compared to the 1Mbps PHY. 

Tim said:

Lastly, as we look to a solution for synchronizing internal peripheral clocks, would you recommend the blog post I link to above? All we need is 10ms accuracy between two peripherals. Wondering if the blog post solution is overkill and we could achieve our 10ms requirement with something simpler.

I think this is the only synchronization solution that we have any source code for I am afraid. Try lowering the connection interval first.

Best regards

Bjørn