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]

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