So is there any way to reduce the receiver power consumption?
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.
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?
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