Central configuration - Discovery fail at MAX_CONNECTION_INTERVAL 50ms, passes at max 20ms

[Ron]

Hi

I am using nRF51822 for central and peripheral, S132, Based SDK12

Attempting to configure the nRF51822 as a central, I am experiencing issues with Discovery process failure, my peripheral connection interval is defined between 20ms-75ms

I have noticed that this is dependent on MAX_CONNECTION_INTERVAL, when I set up interval connection between 10-20ms it works, but if, for example I set it up 10-50ms discovery fails, not all services are discovered upon connection, why is that? is there a way around it?

Thanks

[Kenneth]

Hello,

Do you by any chance have a sniffer log (e.g. using nrf sniffer for ble) that we can look at?

Is it possible that you have slave latency here? Typically I recommend to wait to enable slave latency until the central have performed all the tasks it wants to (e.g. database discovery).

Kenneth

[Ron]

Hi Kenneth,

Yes I can try to sniff our the connection process,

But in the meanwhile, what do you mean by enabling slave latency until after, how do I do it?

Also, is there a way to change the max interval connection after discovery (I mean initiation of updating of connection-parameters by the central side)?

Thanks!

[Ron]

Hey,

I am using nRF51822 for central and peripheral, S130* (s130_nrf51_2.0.1_softdevice.hex)

and SDK12 (nRF5_SDK_12.3.0)

* At the beginning of the thread I mistakenly specified S132, but yes, it's 130#

I see that when calling ble_db_discovery_start, function returns an error 0x11, which I understand means SD is busy?

I am only calling the ble_db_discovery_start  after connection event, and I added 100ms delay, and than a second attempt after another 100ms delay, both fail with 0x11

I understand that changing connection interval might cause increase burden to the softdevice, what should I do than?

Thanks! 

[Kenneth]

Ron said:

I am only calling the ble_db_discovery_start  after connection event, and I added 100ms delay, and than a second attempt after another 100ms delay, both fail with 0x11

The busy typically refer to an on-going BLE transfer(s), so if you have a connection interval of 50ms, then a 100ms delay that might not be sufficient for the on-going transfer(s) to complete such that it no longer report busy, so you can try with even longer delays. That said though, in both failing and working it seems the discovery actually start, so I am not sure this is directly relevant to what you are observing? Or have you found there is an assert occuring due to some error code?

Kenneth

[Ron]

Hi Kenneth

There was an assert due to the busy error, I removed this assert now. and looped around the ble_db_discovery_start until it succeeds with 30ms intervals, it worked, after 34 attempts., so takes more than 1sec to finish discovery.. is that normal?

-------

regarding 

Ron said:

I see that the xtal accuracy is defined by both peripheral and central, how is that negotiated? is that important?

Can you answer my question here? I want to know if it will be a problem if I use a device with internal RC and so can't give good xtal accuracy (so 500ppm), will some centrals (some phones for example) require, regardless, better accuracy (20ppm) and the connection will fail without it?

-------

Thanks

Ron

[Kenneth]

Ron said:

There was an assert due to the busy error, I removed this assert now. and looped around the ble_db_discovery_start until it succeeds with 30ms intervals, it worked, after 34 attempts., so takes more than 1sec to finish discovery.. is that normal?

Indeed odd, can you send me the log?

Ron said:

I see that the xtal accuracy is defined by both peripheral and central, how is that negotiated? is that important?

The connection request packet from the central to the peripheral contains it's own tolerance, the peripheral will use the tolerance of the central +  the tolerance of it's own clock to find the max drift that can occur, it will automatically adjust it's listening window to ensure it can always follow the central. So it is for sure important, but I am not aware of any issues (as long as of course the configured tolerance is correct for the actual source).

Kenneth

[Ron]

Hi Kenneth

Kenneth said:

can you send me the log

Log is attached

DiscoveryAttempts_23_06_07_a0-PASS_Attmpt35.pcapng

I am starting to receive errors on sd_ble_gattc_write - "SD Read/Write API returns error"

DiscoveryAttempts_23_06_07_PASS_a2_Attmpt35+SD Erros.pcapng

--------------

Until recently I didn't mind actually having a small connection interval, but recently I suspected it burdens the softdevice because a write-to-flash on the peripheral side, that previously was successful at first attempt, failed when I used my fw on my own central (it worked with different OEM centrals), the failure was also due to error 0x11 (busy), I thought that the short connection interval I was forcing on the peripheral is causing the soft-device to work too hard, and so tried to get the interval higher (and failed on the discovery).

Now, at least according to some initial test with the new max interval at 50ms, the write-to-flash does appear to be working. and the initial problem might be solved. although new ones might arise

---------------

Kenneth said:

The connection request packet from the central to the peripheral contains it's own tolerance, the peripheral will use the tolerance of the central +  the tolerance of it's own clock to find the max drift that can occur, it will automatically adjust it's listening window to ensure it can always follow the central. So it is for sure important, but I am not aware of any issues (as long as of course the configured tolerance is correct for the actual source).

Thanks for the explanation and in General! 

Ron

[Kenneth]

Ron said:

Log is attached

DiscoveryAttempts_23_06_07_a0-PASS_Attmpt35.pcapng

Looking at this logs it looks like discovery occurs two times?

The event counter it seems to occur about 50events apart. Are you running ble_db_discovery_start two times in a row here?

Kenneth

[Ron]

Hi Kenneth

I am looping around the ble_db_discovery_start until it does not return 0x11, so I am calling it many times, until success, might this cause the double discovery occurance?

Thanks

[Kenneth]

Are you 100% sure ble_db_discovery_start() is not called somewhere else in your code and/or that you for unknown reason miss that ble_db_discovery_start() return success the first time?

Kenneth

[Ron]

Hi Kenneth,

You were right, It returned and re-entered the same loop, calling ble_db_discovery_start() again, I fixed that now.

However, There is another issue, after connection and discovery (seems to) finish successfully , a certain service notification stopped working, after some tests I figured out that

1. the only change that matters to the occurrence of this missing notification is the MAX_CONNECTION_INTERVAL change to 50ms. 

2. On the Wireshark sniffer, the event never been sent from the peripheral, when debugging on peripheral side, it seems error (0x3401) returned by sd_ble_gatts_hvx(), which I understand means BLE_ERROR_GATTS_SYS_ATTR_MISSING, (on the central side, after discovery, notifications are enabled with cccd_configure() returns with no error).

I am adding logs successful results (with 20ms max interval) and the problematic results (with 50ms)

DiscoveryAttempts_23_06_09_PassNotification.pcapngDiscoveryAttempts_23_06_09_FailNotification.pcapng

Any ideas?

Thanks!

[Kenneth]

Hi,

Likely in one of the case there is a small difference in timing that allow the application to handle the BLE_GATTS_EVT_SYS_ATTR_MISSING event before the applicatin have time to call the sd_ble_gatts_hvx() api. The message sequence chart(s) for GATTS System Attributes Handling: Unknown Peer and Bonded Peer show this handling: 
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s130.api.v2.0.1/s130_msc_overview.html 

Kenneth