Any way to reduce power consumption of nRF24L01+ receiver module?

Hi,
I am trying to reduce the power consumption of nrf24l01+ rf module receiver. In case of transmitter module, it takes very less power, because most time it will be in idle mode in my case, takes power only when it is transmitting data. But the receiver is always checking data on air, so it is always taking 14.3 mA of current. So is there any way to reduce the receiver power consumption? By some thing like 'sniff' mode in bluetooth which reduce power consumption(by cheking data on air in regular intervals only), is there any equivalent mode for nrf24l01+ module?

vinodstanur said:

So is there any way to reduce the receiver power consumption?

Click to expand...

Certainly.

Usually these types of design fall into few different scenarios, lets examine the three most common:

1. The master/basestation device which is powered by the mains and one or more remote devices which are powered by battery.

2. The master/basestation device which is powered by the battery and one or more remote devices which are powered by mains

3. Both the master/basestation device and one or more remote devices are powered by battery.

Note: The terms master/basestation refer to the device which either accepts input, provides output or both directly from/to the user.

For scenarios 1 and 2, the device(s) powered by the mains are initially configured as RX device(s), while the battery power device(s) are initially configured as TX device(s).

Examples:

Scenario 1:
You have a battery powered remote (TX) device which collects temperature, humidity and barometric pressure data from its sensors and transmits the data to a mains powered basestation (RX) device which stores and constantly displays and the data and the time on a GLCD.

The remote devices nRF24L01+ module only requires 11mA when transmitting, at regular intervals, scheduled or triggered by an interrupt, otherwise the nRF24L01+ module can either be powered down or put in standby mode requiring very little current.

The master/basestation devices nRF24L01+ module can remain in RX mode as the 14mA from the mains is of little consequence.

If the master/basestation can accept input from the user, possibly temporarily activate an additional sensor, one which requires too much current to be allowed to operate constantly, on the remote device, you can have the remote device switch to RX mode and wait for an acknowledgement (ACK) packet and additional commands issued by the master, carry out the command(s) and then switch back to TX mode and return to a powered down or standby mode.

Scenario 2:

You have a battery powered master/basestation (TX) device which acts as a TV "remote" control which and transmits the data from the user to a mains powered remote (RX) device which a HiDef TV.

Essentially this situation is similar to the initial conditions in Scenario 1, and really requires no further measures.

The main/basestation devices nRF24L01+ module only requires 11mA when transmitting, at regular intervals, scheduled or triggered by an interrupt, otherwise the nRF24L01+ module can either be powered down or put in standby mode requiring very little current

The remote devices nRF24L01+ module can remain in RX mode as the 14mA from the mains is of little consequence.

If the remote device (TV) needs to transmit data to the master/basestation device (TV remote) for some reason, you can have the master/basestation device (TV remote) switch to RX mode and wait for an acknowledgement (ACK) packet and additional command(s) or data issued by the remote device (TV) carry out the command(s) or display the data and then switch back to TX mode and return to a powered down or standby mode.

vinodstanur said:

By some thing like 'sniff' mode in bluetooth which reduce power consumption(by cheeking data on air in regular intervals only), is there any equivalent mode for nrf24l01+ module?

Click to expand...

Yes, the following scenario will demonstrate such a technique.

Scenario 3:

You have a battery powered master/basestation (RX) device, a wrist watch which displays your heart rate and the time, receiving the heart rate data from battery powered remote (TX) device strapped to your chest.

The remote devices nRF24L01+ module only requires 11mA when transmitting, at regular intervals, scheduled or triggered by an interrupt, otherwise the nRF24L01+ module can either be powered down or put in standby mode requiring very little current.

However the master/basestation devices nRF24L01+ module cannot remain in RX mode as the14mA constantly drawn from a watch battery would soon deplete it.

Therefore, at a scheduled interval, every 500ms for example, the master/basestation device (wrist watch) wakes the nRF24L01+ module from power down or standby mode into RX mode and waits for a predetermined period for the remote device (heart rate sensor) which also transmits every 500ms.

After the transmission has taken place the master/basestation device (wrist watch) switches to TX mode and sends an ACK packet acknowledging the successful transfer of data.

Of course there is no guarantee the two devices will be in sync, therefore there are a several possible strategies to deal with this "out-of-sync" situation.

1. You have the master/basestation device (wrist watch) wait a predetermined interval for a successful transmission before a timeout occurs, which if not successful power down or standby and then repeat process, if the listening interval is appropriately long eventually the data will be received.

In this case the number of retries can be limited to ensure the master/basestation device (wrist watch) isn't constantly listening for a remote device (heart rate sensor) which doesn't exist.

2. You have the master/basestation device (wrist watch) initially listen for the remote device (heart rate sensor) transmission a relatively long interval before timing out and flagging the remote device (heart rate sensor) as nonfunctional.

Once a successful transmission occurs either the master/basestation or remote device then syncs their 500ms timer, possibly a sleep/watchdog timer, so the next session will be in sync, if the devices fall out of sync, the master/basestation device (wrist watch) simply repeats the initial process before flagging the remote device (heart rate sensor) as nonfunctional.

The attached document roughly outlines a similar scenario while contrasting the nRF24L01+ and Bluetooth while providing typical current consumption/savings values.

BigDog

Sir at first let me say thanks for your long explanation about the three scenario.
In my case, it comes under case 3.
Both devices are battery operated. But not a button cell, just a rechargable lithium po battery of low mA (say 200mA). Transmitter is like a remote control (same way we control a toy car). It is taking very less current only.

Receiver is taking 13.5mA when continuously monitoring the air.
But a small delay of .25 second is not a problem for me. Also data to be send is just a byte only (control signal)
So I can put the device in sleep mode and make it wake up after each .25 sec and let it monitor air for around 2 or 3 milli seconds. Am I right?

Most time transmitter will not be sending any thing, so when ever I need to send a byte, I can retransmit it for around time > .25 seconds (if not received). So in my case I think no need of any synchronization also since it is not sending continous data in regular time like heart rate monitor etc.
Sir What is your opinion?

Yes, I agree the method set forth in the attached appnote should work.

You may need to tweak various settings to optimize the algorithm to your particular circumstances.

Keep track of the number of retries, if excessive you might consider implementing a method of synchronization.


Another approach would be to configure the master/basestation device (remote control) as RX mode which would only be in an active state when data needs to be passed to the remote device (car) which is configured initially as TX mode.

The remote device (car) transmits a request for data every 250ms and then switches to RX mode and if the master/basestation (remote control) has data to be sent does so after receiving the initial request from the remote device (car).

The master/basestation device (remote control) then switches back to RX mode and waits for a confirmation the transmission was successful form the remote device (car) and both devices are now back in their original mode.

The above approach limits the power consumption by nRF24L01+ module of the remote device to only a few milliseconds per second and eliminates almost entirely any power consumption by nRF24L01+ module except when the master/basestation device (remote control) has data to send.


BigDog

Okay sir, I will try it and will inform you the result.

- - - Updated - - -

Sir you actually mean some thing like this? (below)
the receive should transmit a byte on each 250ms to the transmitter.
When the transmitter need to send any data, at first it will need to wake up and wait for the data from receiver. When it receives, it will be acknowledged by the car and thus the car understood that the transmitter need to send some thing and thus the receiver will switch to RX mode and the transmitter transmits the particular data. So the receiver doesn't need to open any 'RX WINDOW' on each timeslot, instead it sends a byte which will take less time than reveiver window time and thus we could save little more time (power) consumption in the car. This what you mean?

[here 'receiver' means the CAR and 'transmitter' means the 'remote control'](just calling the car as receiver itself even if it is in transmitter mode, also the same case for 'transmitter' also)

vinodstanur said:

Sir you actually mean some thing like this? (below)
the receive should transmit a byte on each 250ms to the transmitter.
When the transmitter need to send any data, at first it will need to wake up and wait for the data from receiver. When it receives, it will be acknowledged by the car and thus the car understood that the transmitter need to send some thing and thus the receiver will switch to RX mode and the transmitter transmits the particular data. So the receiver doesn't need to open any 'RX WINDOW' on each timeslot, instead it sends a byte which will take less time than reveiver window time and thus we could save little more time (power) consumption in the car. This what you mean?

[here 'receiver' means the CAR and 'transmitter' means the 'remote control'](just calling the car as receiver itself even if it is in transmitter mode, also the same case for 'transmitter' also)

Click to expand...

Yes, I believe your description matches my last recommendation.

Perhaps, to avoid future confusion, we should adopt a different nomenclature such as the commonly used coordinator and endpoint.

The coordinator being the device which accepts input from the user and the endpoint the device which performs the desired actions.

In your scenario the coordinator representing the remote control and the endpoint the car.

Have you made any progress at this point?

BigDog

No actually I am designing the hardware first. After that I will go for the software. But I need to confirm that the nrf24l01+ could be used for my requirement, because I was confused to use nrf24l01+ or ANT. That is why I posted this thread. Now I am designing the hardware using nrf24l01+ only..