notification interval varies randomly from application side.

[has]

Hello good morning,

I am using nrf52840 device. I am sending 20 bytes using notification at different notification intervals like 30ms, 80ms and 1sec. But at application side i got the same data but at different interval. At receiving side the packet and its time are as follow.

Data received at 1 sec interval are as follow:

5:25:30:912 1234567891011121314151617181920

5:25:32:11 101102103104105106107108109110111112113114115116117118119120

5:25:33:7 1234567891011121314151617181920

5:25:34:0 101102103104105106107108109110111112113114115116117118119120

5:25:34:996 1234567891011121314151617181920

5:25:35:990 101102103104105106107108109110111112113114115116117118119120

5:25:36:983 1234567891011121314151617181920

5:25:37:977 101102103104105106107108109110111112113114115116117118119120

5:25:38:969 1234567891011121314151617181920

5:25:39:965 101102103104105106107108109110111112113114115116117118119120

5:25:40:958 1234567891011121314151617181920

5:25:41:953 101102103104105106107108109110111112113114115116117118119120

5:25:42:946 1234567891011121314151617181920

5:25:44:337 101102103104105106107108109110111112113114115116117118119120

Data received at 100 ms interval are as follow:

6:42:42:844 1234567891011121314151617181920

6:42:42:936 101102103104105106107108109110111112113114115116117118119120

6:42:43:32 1234567891011121314151617181920

6:42:43:131 101102103104105106107108109110111112113114115116117118119120

6:42:43:277 1234567891011121314151617181920

6:42:43:375 101102103104105106107108109110111112113114115116117118119120

6:42:43:423 1234567891011121314151617181920

6:42:43:569 101102103104105106107108109110111112113114115116117118119120

6:42:43:617 1234567891011121314151617181920

6:42:43:713 101102103104105106107108109110111112113114115116117118119120

6:42:43:812 1234567891011121314151617181920

6:42:43:910 101102103104105106107108109110111112113114115116117118119120

6:42:44:8 1234567891011121314151617181920

6:42:44:105 101102103104105106107108109110111112113114115116117118119120

6:42:44:354 1234567891011121314151617181920

6:42:44:550 101102103104105106107108109110111112113114115116117118119120

time format = [hour:min:sec:milisec]

i just want to know reason behind this variation. I also want some suggestion to conclude the proper data rate.

Thank you

[Edvin]

Hello,

I guess that you are asking why the timings are inaccurate, is that correct?

A BLE connection has a connection interval. If two devices are connected with a connection interval of 100ms, you can queue (send data via notification) packets at any time, but they will not be sent until the next connection interval.

So if you want to send data once every second, you should select a connection interval that is 1 sec is dividable by. E.g. 0.5s, 0.25 sec, 0.1 sec, or something else that will add up to one second.

Do you control both the central and the peripheral? To set a specific connection interval, you can just set the MIN_CONN_INTERVAL = MAX_CONN_INTERVAL = your desired connection interval. you can set the same on both devices.

Remember that this value is given in units of 1.25ms, so 1 second = 800 units, 100ms = 80units.

Best regards,

Edvin

[has]

Hello Edvin,

Thank you so much for your kind response. You understood my question very well. Thanks for that.

I understood your point related to connection interval and it is helpful to us to test the system with different-different notification interval.

Yes, we are developing on both, peripheral - nRF hardware device and central - android mobile application. From hardware device we are able to configure connection interval as per your inputs. From android application side, we explored and found that there is no API available to configure connection interval. Also we found that after marshmallow version, BLE SDK provides 11.25ms connection interval. Do you have any idea how can we configure connection interval time in android application side?

Previously our MIN_CONN_INTERVAL and MAX_CONN_INTERVAL are 100 ms and 200 ms respectively. That time if we set notification interval to 30 ms then after sometime i.e. 30 second mobile application cannot receive the data and disconnect the BLE. Now this problem is resolved after applying your inputs related to connection interval. Thanks for that again.

Still we are getting one problem in this case. Please find below configuration.

- MIN_CONN_INTERVAL - 10 ms

- MAX_CONN_INTERVAL - 20 ms

Test case 1: Notification interval 30 ms: We found that timing between two packets are too much varied at mobile application side, sometime it shows 2 ms and maximum variation we can see is 100 ms.

Test case 2: Notification interval 100 ms: We found that timing between two packets are 120 ms and in rare case it shows 2 ms.

Test case 3: Notification interval 200 ms: We found that timing between two packets are 240 ms and in rare case it shows around 100 ms.

Can you please guide us on why this kind of time variation occurs?

Appreciated for your help.

Thank You.

[Edvin]

Hello,

This may be due to a bad link. If there is a lot of rf-noise, then some packets may be lost, and they should be retransmitted. Regarding setting the connection interval with phones, I am not sure how easy it is to control this on different phones. I know that at least iOS will only let you chose between a few given connection_intervals.

Have you tried to sniff the connection using e.g. nRF Sniffer?

Then you can see what connection interval you actually have, and how many of the connection interval events that contain data.

The problem is that if you are in a noisy environment, and the link looses a packet, the softdevice will automatically try to re-transmit this packet, without letting the application know. Depending on your connection settings (MTU and DLE), if you send large packets, the softdevice will split it up into several packets, so if you send two types of packs with different lengths, then one might be split into two, while the other isn't, which may cause some different timings in when they are received and put back together before it is delivered to the application.

Best regards,

Edvin