I'm considering building a handheld radio receiver based on an nRF24L01+ and an ATtiny chip. It needs to receive "continuously", to receive a control signal that might operate some attached LEDs or make a tone from the PWM controller. However, due to power concerns of being battery-operated, I wonder if it makes sense to operate the receive in pulses, instead of continuously.

For example, I could have the receiver enabled only 1msec, every 20msec, thus reducing its power requirement to approximately 5% (with a slight hit on the ATtiny of running a timer to perform this, but that's still an overall net saving). This gives a worst-case latency of receiving a signal at around 20msec, which is fine for my purposes of controlling an LED. It means the transmitter should run a strategy of something like transmitting a packet every 500uSec for 25msec, but that's OK because this transmitter is mains-powered so there aren't such concerns of achieving low power there.

Is this a sensible plan? Am I actually likely to achieve a good power saving by such a strategy, at the additional cost of code complexity on the ATtiny, and added on-air congestion from transmitting the same packet 50 up to times?

(See also my related question How does the nRF24L01+ performance degrade with supply voltage?)

  • \$\begingroup\$ If the other party is always enabled, why not ask that other party for the current status its wants the LED to be? That would eliminate the 'congestion' and reduce the latency. \$\endgroup\$ – Wouter van Ooijen Jul 5 '14 at 16:16
  • \$\begingroup\$ Look into how much the module consuming now. If it is consuming fraction of the whole power, it may not be viable. \$\endgroup\$ – nvd Jul 8 '14 at 12:24

Look into how much the module is consuming now. If it is consuming a fraction of the whole system power, it may not be viable.

Check if you can disable TX of the receiver to save some power. Run the MCU using watchdog so that it wakes up, does the job and sleeps again.

To sync communication, send a request packet from the receiver to the transmitter for every update. In that way, you will not be transmitting when receiver is offline and expecting trial and hit packets; receiver controls the flow. By changing the frequency of requests, you control the frequency of updates and power consumption.

Thus, in the most optimal way, use watchdog timer to wake up MCU. After wakeup, enable the receiving module (both RX and TX if they can be controlled separately). Send a request packet. Wait for the packet with a timeout. If a packet is received before timeout, use it for the update and sleep. If timeout occurs, sleep.

  • \$\begingroup\$ Yes; this seems like a good idea. With my PC-coding hat on the idea of a polling interface seems bad, but on further thought, it may lead to better battery performance to have the "receiver" modules periodically poll the base station for status updates. \$\endgroup\$ – LeoNerd Jul 8 '14 at 16:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.