about current consumption (sd_app_evt_wait())

[wataru_m]

Hi team,

Does the nordic chip receive a Bluetooth signal being communicated with a mouse, keyboard, cell phone, etc.,
and the sleep state (sd_app_evt_wait()) is canceled?
I will write down the circumstances leading up to this question below.

As far as I read the explanation of sd_app_evt_wait (),
I thought that the CPU would go to sleep,
but when I measured the current consumption I consume more than I imagined, so I decided to experiment.
I conducted an experiment with one hypothesis about the behavior of sd_app_evt_wait () in an infinite loop (for (;;)).

In the example of light_switch, execution_start (start) is executed after initialize () is called. (default)
After that, as far as I see the program, we expect to enter the for (;;) loop and let the CPU sleep with sd_app_evt_wait ().

In order to check whether the CPU is really sleeping, I added a __ LOG print sentence under sd_app_evt_wait () in the loop.
If the CPU is sleeping, I think about __LOG () is never output on the RTT viewer, right?

However, when I tried it a lot of __LOG () was output on the RTT viewer.
I did not press any button and did not anything.
Just it connects the PC and the evaluation board and outputs the execution result on the RTT viewer.

I tried to eliminate things that would cause interruption little by little.

I commented out
rtt_input_enable ()
and ERROR_CHECK (mesh_stack_start)
in static void start (void) of main.c.

Then, the __ LOG output is only once.

As I first asked, do CPU wake up from sd_app_evt_wait () by receiving Bluetooth communication of the mouse, keyboard or etc.?


my development environment :
nrf52840 (third party module)
nRF5_SDK_15.0.0
nRF5_SDK_for_Mesh_v2.2.0
Segger Embedded Studio


Best regards, 
Wataru

[Hung Bui]

Hi Wataru,

The way the sd_app_evt_wait () works is that it would put the CPU to sleep and halt the execution until there is any app interrupts (including softdevice's events that are sent to the application) . But the softdevice is independent from that, meaning the CPU can also be used to handle the softdevice task, for example to keep the communication on BLE (mouse, keyboard for example). 

 However, the example you tested with was not just a normal BLE example. You were testing with a mesh example. With the mesh stack, things work a little bit different. We have 2 stacks, one is the softdevice and one is the mesh stack. And they both work at the same time. The mesh stack actually request a timeslot from the softdevice to work. And the mesh stack wouldn't follow what designed in sd_app_evt_wait(), it will wake up the CPU out of that sleep when there is any mesh event. 

It's not expected to have low power consumption with mesh examples since the radio has to scan all the time, except for the Low power node example experimental_lpn . This is available from Mesh SDK v3.x. Please read more about that example here. 

[wataru_m]

Hi Hung,

Thank you for your reply.
In the example of normal BLE, I intended to understand
that the sd_app_evt_wait()  works and the CPU sleeps and halts until an interrupt occurs.

But, I have not understood exactly what softdevice actually does.
Does softdevice manage function related the radio?


"the mesh stack wouldn't follow what designed in sd_app_evt_wait(),
it will wake up the CPU out of that sleep when there is any mesh event. "

For example, what is the event like?
I could only think about relays, send / receive.

In the environment without other Bluetooth communication,
if the all nodes are not emitting radio waves, will any events occur?

I can imagine little bit that the node is always scanning radio.
Is the scan done by softdevice too?
(Does that cause the CPU to wake from sleep?)

I would like to know whether the CPU goes to sleep or does not sleep when this sample is executed at a place where Bluetooth packets are not flying at all.


※ Actually I want to make it operate as a normal relay node, not a low power node.


Best regards, 
Wataru

[Hung Bui]

Hi Wataru, 

The easiest to have a profile of the CPU activity is to use a power profiler kit.  With the tool you can easily see when the CPU is active and when it's only the radio (based on the current consumption). 

Regarding your questions, yes the softdevice handle the BLE protocol, including waking up the radio, scan, send radio packet if needed, wakeup the CPU if processing needed, send CPU event if there is BLE event. 

The mesh stack's events could be as you said scan, relay, send, receive, but also can be timeslot event. (Timeslot is a slot of time that the softdevice grant to the mesh stack. It's not infinitive and need to be requested periodically )

In an environment without Bluetooth and mesh communication, I would assume there will be very little CPU activity and the CPU should stay in sleep mode (current consumption at 5-8mA  as the radio is in scanning mode )

Which current consumption result do you have when you do measurement ? 

[wataru_m]

Hi Hung,

Thank you for your reply.
I can not judge whether I can buy a profiler kit, so I will consult with my boss.

I understood a little about the function of softdevice. Thank you.

You said softdevice grants to slot of time to mesh stack,
but how long is that regular interval? (ms)order? (us)? (sec)?

In the office where Bluetooth communication flies from the keyboard or mobile,
when measuring current consumption using a USB type ammeter, it got about 15 mAh.
I think this is a bit too much.

I attach the data sheet of the module I am using.


This document says that it is irrelevant to software, but it seems to be 4.8 mA in RX only.
This is close to value that you said(5-8 mA) .

I thought whether transmission output is involved,
and even if I edited advertiser.c as follows, it did not change.

static inline void set_default_broadcast_configuration(broadcast_t * p_broadcast)
{
    p_broadcast->params.access_address = BEARER_ACCESS_ADDR_DEFAULT;
    p_broadcast->params.radio_config.payload_maxlen = RADIO_CONFIG_ADV_MAX_PAYLOAD_SIZE;
    p_broadcast->params.radio_config.radio_mode = RADIO_MODE_BLE_1MBIT;
//  p_broadcast->params.radio_config.tx_power = RADIO_POWER_NRF_0DBM;
    p_broadcast->params.radio_config.tx_power = RADIO_POWER_NRF_POS8DBM;
//  p_broadcast->params.radio_config.tx_power = RADIO_POWER_NRF_NEG40DBM;
}

In the mesh network, if none of the events occur, will the CPU go to sleep mode?
(But in that case, since the node is always receiving, the current consumption is about 5 -8 mA?)


Best regards,
Wataru

[Hung Bui]

Hi Wataru,

To get an overview of what the current consumption should be please have a look at section 5.2 in the NRF52840 product specification v1.0 

Note that the current consumption of 6.4 mA achieved when you enable DCDC. If no DCDC enabled the current consumption when scanning can get up to 12mA. 

Could you try to measure current consumption on an unmodified mesh light switch client example ? I measured the current consumption and it matched with the above number. 

I would suggest to do measurement on a nRF52 development kit as a golden sample to compare to the 3rd party module. 

I don't have the exact number of how often the timeslot is requested. As far as I remember we re-request the timeslot every 10 seconds. 

[wataru_m]

Hi Hung,

Currently I am measuring current consumption with an unmodified sample (light_switch_client).
I will tell you again when I know the results.

By the way, is DC / DC enabled for the default sample?
Also, is the server example current consumption the same as the result of client?

Your company's DK is might not certified in my country and I think that it can not be used. . .

I do not know exactly, but is my understanding that the timeslot request does not occur frequently correct? (e.g. ms order)
In other words, does the timeslot request may occur about every 10 seconds and the CPU returns from sd_app_evt_wait ()?
(In an environment without Bluetooth packet)

Best regards,
Wataru


[Update]
As a result of experimenting in the office, it consumed about 13 to 15 mAh as well.
Since the Bluetooth communication can not be completely blocked, the accuracy of the data may be lacking...