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]

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

[Ron]

Hi Kenneth 

Honestly I am not sure I understand your answer, what do you suggest I do to solve my problem?

Thanks!

[Kenneth]

It's up to you really, the simplest may be just to try again repeatedly every 10ms until success or just discard the data if it is real-time data that may not have any use 10ms later. Alternatively wait to call sd_ble_gatts_hvx() until the peer have enabled notification.

Kenneth