sd_ble_gap_adv_stop takes long sometimes

[eleven-x_devteam]

Hi,

I am working on handling multi-radio protocols like only 1 radio at a time. (https://devzone.nordicsemi.com/f/nordic-q-a/63194/when-the-timeslot-extension-could-be-failed)

Since I decided to stop advertising before other radio jobs, I am using sd_ble_gap_adv_stop() for stopping advertising but it sometimes takes long such as 6~7 seconds. (time between the logs below) 

It usually happens after the very first advertising start or after advertising is being done for a while like a minute.

[code]

 log("ble_stop_advertising begin\r\n");

 ble_advertising_t* const p_advertising = &m_advertising;

 uint32_t ret = sd_ble_gap_adv_stop(p_advertising->adv_handle);

 log("ble_stop_advertising done: %d\r\n", ret);

Could it happen sometimes? or Is there any solution to improve it?

Thank you.

[Karl Ylvisaker]

Hello,

What error code does the call to sd_ble_gap_adv_stop return with?
Are you using the BLE Advertising module?

Additionally, could you verify for me whether you are using the deferred logging option? This might cause the logs to be printed first when the CPU is idling, which may cause a large delay between log-call and the log being written out. In general, using log statements to measure time is not a recommended practice, due to logging's high resource usage and low priority.

Best regards,
Karl

[eleven-x_devteam]

Karl Ylvisaker said:

What error code does the call to sd_ble_gap_adv_stop return with?

it returns 0 I guess NRF_SUCCESS.

Karl Ylvisaker said:

Are you using the BLE Advertising module?

If you mean components/ble/ble_advertising/ble_advertising.c, then yes. I am using "examples\ble_peripheral\ble_app_uart" as a base code and just added stop advertising code like up there.

Karl Ylvisaker said:

could you verify for me whether you are using the deferred logging option?

I am not using not nrf log and deferred logging option but right the log was delayed and the taking long time issue is from not stopping advertising but request_next_event_earliest for timeslot.

I was using while loop with  nrf_delay_us and retrial time to get success for timeslop open and request_next_event_earliest.

I am not sure if it is proper.

Additionally, now I am getting fail to open time session as well.

If ble is not connected and advertising is disabled, timeslot open should get success, right?

[Karl Ylvisaker]

Hello,

eleven-x_devteam said:

it returns 0 I guess NRF_SUCCESS.

This is good - so the advertising stops as it should, and the call is successful.

eleven-x_devteam said:

I am not using not nrf log and deferred logging option but right the log was delayed and the taking long time issue is from not stopping advertising but request_next_event_earliest for timeslot.

I was using while loop with  nrf_delay_us and retrial time to get success for timeslop open and request_next_event_earliest.

I am not sure if it is proper.

So the problem was not stopping advertisement, but rather requesting the next timeslot, understood.

eleven-x_devteam said:

Additionally, now I am getting fail to open time session as well.

Please be specific - which error code is generated, and what function is returning the error?
There could be another component of your code causing this error.

eleven-x_devteam said:

If ble is not connected and advertising is disabled, timeslot open should get success, right?

If the SoftDevice has not scheduled any radio activity then yes, this should success.

It is hard to pinpoint what is happening in your project without knowing more about it.
Therefore, I have attached a project that is a modification of the ble_app_uart peripheral example for SDK v.15.0.0 that requests the maximum possible timeslots. The LED 2 is ON while the timeslot is active. Perhaps seeing this could help you resolve the issues you are facing in you project. Please place the project in SDKv15.0.0\examples\ble_peripheral\ if you intend to compile it.
All the timeslot related code is located in max_timeslot.c/.h.
You may also see the percentage of the time available to the timeslot printed to the RTT viewer.

Looking forward to resolving this issue together,

__ble_app_uart_maximum_timeslot.zip

Best regards,
Karl

[eleven-x_devteam]

Thank you for the code.

It works but it is different from my code. 

I was using sd_radio_session_open / sd_radio_session_close whenever the other radio request timslot and finish it but __ble_app_uart_maximum_timeslot call sd_radio_session_open just once and keep it open and try sd_radio_request whenever the previous request extension fails.

Do I need to call sd_radio_session_open  only once and is it OK to leave it open like even when device reset?

[eleven-x_devteam]

I think that the issue is related to max extension time.

When I change the max extension time from 128 secs to 1sec, the delayed returning from request_next_event_earliest problem disappeared.

I think the delay can happen while extension keeps going up to 128 sec even after sd_radio_session_close was called. Does it make sense?

[Karl Ylvisaker]

eleven-x_devteam said:

Thank you for the code.

No problem at all, I hope you found it useful to have a look at!

eleven-x_devteam said:

It works but it is different from my code. 

eleven-x_devteam said:

Do I need to call sd_radio_session_open  only once and is it OK to leave it open like even when device reset?

You may leave the session open, but you may only have one open session at the time.
Please see the sd_radio_session_open API Reference for further detail.

eleven-x_devteam said:

I think that the issue is related to max extension time.

The maximum extension time in the provided example is only to demonstrate how much time that is available for non-SoftDevice functionality. 

eleven-x_devteam said:

I think the delay can happen while extension keeps going up to 128 sec even after sd_radio_session_close was called. Does it make sense?

I have not verified this myself, but I suppose this is what happens, yes. As per the documentation : "any current radio timeslots will be finished before the session is closed"
So I would think that is what happens.

If you are not using the SoftDevice for anything, then you may request as much timeslots as you would like and the SoftDevice will grant it - since it has no use for the radio itself.

Best regards,
Karl

[eleven-x_devteam]

Problem resolved with 1 sec extension. Thank you!