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!

[Kenneth]

Hi,

Please sniff the connection when working and failng, it will be easier to understand what is actually happening then. 

In short: Slave latency control how frequently the peripheral must listen at a given connection interval, it can skip slave latency periods.

In short: Yes.

Kenneth

[Ron]

Hi Kenneth

Here are the wireshark results, passing and failing

Discovery_23_05_06_FAIL_b000.pcapng

Discovery_23_05_06_PASS_b000.pcapng

If you think the solution is to update the latency, or max-interval, please refer me to an example on how-to?

Thank you for your help! 

Ron

[Kenneth]

The sniffer logs helped a bit. Looks like my first assumption is likely wrong.

Instead, can you look into what lfclk configuration you have provided in ble_stack_init()?

Typically you can find something like this in ble_stack_init():

nrf_clock_lf_cfg_t clock_lf_cfg = NRF_CLOCK_LFCLKSRC;

// Initialize the SoftDevice handler module.
SOFTDEVICE_HANDLER_APPSH_INIT(&clock_lf_cfg, true);

I need to know wht you have set .xtal_accuracy to for the lf clock configuration, and in specific (at least for test) suggest to use NRF_CLOCK_LF_XTAL_ACCURACY_500_PPM. But I would like to know all the paramters you have used for source, rc_ctiv, rc_temp_ctiv and xtal_accuracy.

Kenneth

[Ron]

Hi Kenneth,

I understand, makes sense, this was my configuration, 

#define NRF_CLOCK_LFCLKSRC      {.source        = NRF_CLOCK_LF_SRC_XTAL,            \
                                 .rc_ctiv       = 0,                                \
                                 .rc_temp_ctiv  = 0,                                \
                                 .xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM}

After trying to update the accuracy to 500ppm as you suggested on the central side (while keeping max interval as 50ms), but it failed again

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

On the peripheral side, I am in no position to update the peripheral xtal-accuracy init parameters (peripheral side) as the peripheral is already in the field, with customers, but I did it just in the sake of the experiment and it still failed..

Any other directions of investigations?

Thanks! 

[Kenneth]

Hello,

The communicaiton is abruptly stopped by the central stop sending any packets:

It's very weird, are you sure the central does not assert or reset in any way here? It seems as if there is something fundamentally occurs that cause the central to stop sending packets or that is an unknown electrial/software issue that for unkown reason cause it to shift timing (something I can't remember seeing before) or possible using wrong channel (something I can't remember seeing before either).

Can you specify exactly what SDK and softdevice you are using? Ref:
https://infocenter.nordicsemi.com/topic/comp_matrix_nrf51/COMP/nrf51/nRF51422_nRF51822_ic_rev_sdk_sd_comp_matrix.html 

Kenneth

[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