Reduce current of peripheral thru latency setting?

RE: Reduce current of peripheral thru latency setting?

abc — Tue, 03 Dec 2019 17:34:10 GMT

This is old, but just thought I'd suggest that you use your current-constrained device in central/master mode if possible. Then you would presumably get more deterministic behavior from the SoftDevice controlling the link.

RE: Reduce current of peripheral thru latency setting?

run_ar — Wed, 21 Feb 2018 10:16:24 GMT

Unfortunately we do not have an example in the SDK anymore. But you can look at the example in nRF5_SDK_11.0.0_89a8197\examples\ble_peripheral\experimental_ble_app_multiactivity_beacon. Much have changed in the SD, but I am pretty sure the timeslot api is the same.

RE: Reduce current of peripheral thru latency setting?

rgrr2 — Wed, 21 Feb 2018 10:02:38 GMT

thanks for the suggestion. Do you have an easy to use example for doing this?

RE: Reduce current of peripheral thru latency setting?

run_ar — Wed, 21 Feb 2018 08:30:18 GMT

I understand. Seems like the local slave latency is overridden during the service discovery procedure, so it will not help your application. Unfortunately there are no option to enforce local slave latency. I think the last possible solution to this would be to use the timeslot api in an effort to block ble communication. Could you try setting up a timeslot event with high priority and see if this helps to limit ble traffic?

See sd_radio_request , sd_radio_session_open,

RE: Reduce current of peripheral thru latency setting?

rgrr2 — Fri, 16 Feb 2018 19:04:50 GMT

The picture below shows connection establishment done with LightBlue Explorer. With our application the graph is quite similar except that the actual communication starts on the right side.

But as already said, our problem is connection establishment. Android (>=7) switches to high speed during GATT queries and there is nothing we can do about it, how it sets the connection interval and how the softdevice is responding.

For the record: for the high speed interval in the center and the right part, local slave latency was set to 4.

Image shows module current measured on an in series 200R. There are some capacitors on the module, so one does not see the actual current consumption but the recharging current.

Another note: this connection is successful but the 1mA limit is close. And there is really no margin for CPU activity.

My idea would be to solve the situation thru a force local slave latency, which skips some connection events even if there are pending packets in the queue.

Any suggestions are welcome.

Hardy

PS: peak on the left shows BLE_CONNECT, in the center of the image connection setup is (6,6,0,2000), on the right side it is at ~(32,32,0,2000)

RE: Reduce current of peripheral thru latency setting?

run_ar — Fri, 16 Feb 2018 09:01:15 GMT

Can you also confirm your application does not try to send any data at the time it is supposed to ignore the connection event?

RE: Reduce current of peripheral thru latency setting?

rgrr2 — Thu, 15 Feb 2018 22:41:10 GMT

What do you mean with "not unless you use the standard slave latency"?

Standard slave latency is "0", and the sd call returns NRF_SUCCESS and the p_actual_latency shows the wanted value.

But unfortunately I cannot see any effect, i.e. radio on/off events are still in the interval period.

RE: Reduce current of peripheral thru latency setting?

run_ar — Thu, 15 Feb 2018 20:14:01 GMT

EDIT: I'm sorry, there is no other way to force the softdevice to ignore connection events. What do you mean when you say it does not work? what is returned in the sd call? and are you following the guidelines in the documentation?

RE: Reduce current of peripheral thru latency setting?

rgrr2 — Tue, 13 Feb 2018 16:56:07 GMT

Unfortunately the local slave latency does not seem to work... is there another way to make the softdevice ignore connection intervals?

RE: Reduce current of peripheral thru latency setting?

run_ar — Mon, 05 Feb 2018 11:56:50 GMT

If you are able to work around this by using the local connection latency feature until the connection parameter update is finished you can do that. But be aware that there is a risk you might loose the connection if you use the local connection latency feature. but if you run out of power I guess you are in the same situation...

RE: Reduce current of peripheral thru latency setting?

rgrr2 — Wed, 31 Jan 2018 11:20:50 GMT

thakns for the input. With standard slave latency I guess you mean the API sd_ble_gap_conn_param_update()? This is too slow. In my case the 7.5ms connection interval during connection setup is the problem. Some Android devices ignore the requested parameters and instead try to use 7.5 slots which is too fast for the current limited device. I recognized, that even when setting the local slave latency, the radio notification still shows 7.5ms connection intervals. Which means, that the device "crashes". Really too bad. Any other idea how to switch temporarily the radio to slow motion?

RE: Reduce current of peripheral thru latency setting?

run_ar — Wed, 31 Jan 2018 10:16:27 GMT

In general I would not recommend that you use the Local connection latency feature as there is a risk your device might disconnect in case of a channel map update or other procedures that happens at a specific instanse (the local slave latency feature is proprietary and will work most of the time, but there are corner cases that will lead to link loss). In stead I could recommend using the standard slave latency if possible.