Average connection latency for nRF52840

[johnnyR]

Hi, 

I'm trying to collect data for average latency for nRF52840 using an Android Smartphone as Central and nRF as peripheral.

Latency is being measured by the Android App developed. Latency in my application is defined as the period from when the Android App started scanning until it has successfully established a connection with the nRF. After the Android App discovered the address of the nRF, it will stop scanning and then tries to connect to it.

Prior connection, nRF is always advertising at 100ms advertising interval. I'm quite surprised that I get measurements with a very large variation. From min = 249ms to max = 9376ms with an average of 1672.17ms. Are these values expected? Or they are too long for the configured advertising interval which is 100ms?

Y axis : Latency in ms

X axis : Trials

Kind regards,

Erick

[Karl Ylvisaker]

Hello,

Prior connection, nRF is always advertising at 100ms advertising interval. I'm quite surprised that I get measurements with a very large variation. From min = 249ms to max = 9376ms with an average of 1672.17ms. Are these values expected? Or they are too long for the configured advertising interval which is 100ms?

It is very hard to say, because it depends a lot on other factors than just the advertising interval. For example, are you testing in an environment with a lot of 2.4 GHz noise? Or perhaps without line-of-sight between the devices? 
Do you know exactly how often the central is scanning?
What is your central's scan interval and window? It could be that these do not match the advertising interval of the peripheral very well, which could cause these occasional latency spikes.

If you are looking to minimize the latency in establishing a connection, you could also look into using directed fast advertising, on your peripheral device.

Best regards,
Karl

[johnnyR]

I am at an office space so I guess there is a good amount of noise in the area. The devices are only few inches apart, no more than 1 feet. The central is configured to have a 4.096s scan window and 4.096s scan interval so it would be scanning all the time to make sure it sees the advertisement of the nRF. Is this implementation correct? 

[johnnyR]

I have a question tho, is it possible to track the Connect_request packet going out of the smartphone and being received by the nRF peripheral? 

Kind regards,

Erick

[Karl Ylvisaker]

Hello Erick,

Thank you for your patience.

johnnyR said:

The central is configured to have a 4.096s scan window and 4.096s scan interval so it would be scanning all the time to make sure it sees the advertisement of the nRF. Is this implementation correct? 

Yes, this is correct - when scanning window and intervals are equal, that means it will scan 100% of the time.

johnnyR said:

I have a question tho, is it possible to track the Connect_request packet going out of the smartphone and being received by the nRF peripheral? 

This is possible, yes. Are you familiar with the nRF Sniffer? It is a powerful tool to wield when developing with BLE, as it lets you monitor the on-air traffic. It could be very helpful to see a sniffer trace of this communication, to understand what is happening on the air.
If you select your peripheral device from the dropdown device menu in wireshark, it will filter out any communication not related to this particular device.
If you could capture one trace in which it takes abnormally long to connect, and one trace which is normal, and send it to me I'll take a look and see if I cant spot any possible causes for the long delay.

Best regards,
Karl

[johnnyR]

Hello Karl,

Yes im familiar with the nRF Sniffer, we've used that a lot to monitor the traffic. But Im afraid, selecting the peripheral device wouldn't expose the connect_request packet sent by the smartphone, we would only see the advertisements broadcasted by the peripheral, hence, we still wouldnt find out if there are missed or failed connect requests. Are there other ways to do this? 

Kind regards,

Erick

[Karl Ylvisaker]

Hello Erick,

johnnyR said:

Yes im familiar with the nRF Sniffer, we've used that a lot to monitor the traffic.

Great!

johnnyR said:

But Im afraid, selecting the peripheral device wouldn't expose the connect_request packet sent by the smartphone, we would only see the advertisements broadcasted by the peripheral, hence, we still wouldnt find out if there are missed or failed connect requests. Are there other ways to do this? 

If you have selected the peripheral device, you will see both inbound and outbound communication for that device. So, you will initially only see its advertisements, and the occasional stray scan request and response, and you should also see incoming connect requests.
Have you tried this, and are you not seeing the connect request come in?

Please try this, and let me know if you do not see the connect request packet in the sniffer.

Best regards,
Karl