nrfgo current consumption slave latency

RE: nrfgo current consumption slave latency

awneil — Tue, 20 Sep 2016 09:04:18 GMT

According to Nordic:

The chip wakes up to do some maintenance every connection interval regardless of whether data has been received or not. The radio however, is not necessarily active unless you have data to send. I.e. the chip is actually waking up to check if it has something to do, and if not just goes back to sleep.

Which seriously reduces the benefit of Latency!!

RE: nrfgo current consumption slave latency

awneil — Tue, 20 Sep 2016 09:03:57 GMT

An update on this:

Observing the current consumption, I see "large" peaks as expected where the device has data to send.

But I also see "small" peaks at the Connection Interval when the device has nothing to send - so, due to latency, the nRF8001 should be asleep. These peaks are ~5mA.

Nordic suggest that what I am seeing is IMCU_HOST (Peak current for host processing). Refer to the nRF8001 PS Chapter 12.4 Table 14, and see Fig 17.

It seems that the description on page 40 is a bit misleading:

Data post processing period, enabled only if data has been received

It is not (entirely) true that this happens "only if data has been received" - it always happens.

RE: nrfgo current consumption slave latency

awneil — Thu, 07 Jul 2016 10:28:55 GMT

I was observing the current consumption

RE: nrfgo current consumption slave latency

Amit — Thu, 07 Jul 2016 10:01:33 GMT

@awneil good to see this revived. How can you tell the nrf is actually listening?

RE: nrfgo current consumption slave latency

awneil — Thu, 07 Jul 2016 09:52:26 GMT

We seem to be seeing a similar effect:

The Bluetooth Core specification v4.0, Vol. 6, Part B, section 4.5.1 states:

"The connSlaveLatency parameter defines the number of consecutive connection events that the slave device is not required to listen for the master" (my emphasis).

The nRF8001 Datasheet, Rev 1.3, section 24.18.3 says:

"The number of consecutive connection events that the slave isnot required to respond" (again, my emphasis).

In our application, it appears that the nRF8001 is still listening during the latency time - even if it doesn't respond.

If so, it would defeat a substantial amount of the gain of using Slave Latency.