Failure of nRF24L01 powerUp mode?

Hello,

I am installing a remote sensor array on an existing weather monitoring station. Thanks to the help of forum members here (Whandall and Robin2), data transmission using nRF24L01 radios is working well.

Since the remote arrays will be solar powered, and because the data requests from the master will occur at very regular and predictable intervals (1 minute), it seemed to make sense to keep the nRF radios in powerDown mode for about 55 seconds of each minute in order to conserve power. But there is a problem.

The measured power consumption of the Arudino Nano controller plus nRF in normal listening mode is about 65 mA. In response to a powerDown code instruction, the power drops by about 10 mA. BUT -- there is no response to powerUp instructions and the radio remains unresponsive.

Code (to simply power the radio up and down repeatedly, at 3 sec intervals):

/*power up-down debugging*/

#include <SPI.h>
#include <nRF24L01.h>
#include <RF24.h>

bool radio_on = true;
const byte thisSlaveAddress[5] = {'R', 'x', 'A', 'A', 'A'};
char payload = 'A';
unsigned long interval_start = millis();
unsigned long led_start;

RF24 radio(9, 10);  //CE and CSN, respectively

void setup() {
  pinMode(3, OUTPUT); //for LED indicator
  radio.begin();  // set up radio in standard listening mode
  radio.setDataRate( RF24_250KBPS );
  radio.openReadingPipe(1, thisSlaveAddress);
  radio.enableAckPayload();
  radio.startListening();
  radio.writeAckPayload(1, &payload, sizeof(payload)); // pre-load data
}

void loop() {
  if (millis() - interval_start > 3000) {
    if (radio_on) {
      radio.powerDown();
      digitalWrite(3, HIGH);  //flash an led at each state change
      led_start=millis();
      radio_on = false;
    } else {
      radio.powerUp();
      digitalWrite(3, HIGH);
      led_start = millis();
      radio_on = true;
    }
    interval_start = millis();
  }
  if (millis() - led_start > 50) {
    digitalWrite(3, LOW);
  }
}

Observation:
On startup, current draw is at 65 mA for 3 sec. The LED then flashes and current drops to 55 mA. Subsequently, the LED flashes every 3 sec, but the current remains at 55 mA. Also, the CE pin starts out high, drops low after 3 sec, and never goes high again.

I can look at register values or try pushing CE back high with a manual digitalWrite instruction, but wanted to see if anyone else has experience with this. (Also, tinkering is very unpleasant right now due to frigid temps...)

Thanks,

Steve

Sorry ... IGNORE that post. I have determined that a simple radio.startListening() after the powerUp instruction appears to restore operation. So both instructions are necessary. I'm guessing that the powerUp instruction alone puts the radio in its Standby-I state... which could be useful.

Sorry for jumping the gun..
S.

If you want to save power, drop that master/slave stuff.

Let them sleep, send their data and go to sleep again.

No synchronization needed, maximal sleep time.

Whandall:
If you want to save power, drop that master/slave stuff.

Let them sleep, send their data and go to sleep again.

No synchronization needed, maximal sleep time.

I had thought that implementing the powerDown and powerUp functions would be a quick and easy way to save a few mA. Once again I was wrong. And I was ALSO wrong that radio.powerUp() followed by radio.startListening() restores the radio to its normal listening state. It does not. The current to the device resumes a higher level, the CS pin goes high, but the radio does not respond. Why is nothing simple? ARRGGGHHH.......

Whandall:
If you want to save power, drop that master/slave stuff.

Let them sleep, send their data and go to sleep again.

No synchronization needed, maximal sleep time.

Forgive my frustration and failure to fully answer the question.

  1. I don't know how to sleep a Nano, and I'm sort of committed to the Nano, or at least something with the same footprint and pinout (at least in the short term).
  2. The Arduino isn't idle during the rest of the minute; it is doing other things. It's only the radio which is unneeded for most of each interval.
    S.

If you use an Arduino Pro Mini (with about the same footprint as the Nano) and remove the voltage regulator and power LED, it will sleep at about 100 nanoAmperes. Batteries last the shelf life at that current draw.

Example project of a solar powered bare bones setup with radio.

jremington: thanks for the reference.

As I mentioned, the solar-powered remote array will [ideally] be constantly monitoring wind speed (and some other things as well) to generate both average and maximum over each collection cycle. The solar panel is a 10W unit, which I think should be sufficient to the task (but much more experimentation is in order here). If not I may have to move to something like you suggest.

Among other things, Gammon's example is useful for its code example. I see that he redefines the radio with each call to sendVoltage, rather than using the library powerUp instruction. To me this suggests that he had the same problem with waking the radio up as I am having. In my case, after a powerDown and powerUp cycle, the radio is acknowledging but the ack packets are always empty. This is of no use to me, since they are what will carry the actual data.

So ... I'm still interested in hearing if anyone has run into this issue with powerDown and powerUp on the nRF24L01. I'm using TMRh20's RF24 ver. 1.3.9, BTW. Gammon's radio management approach is something I can try in the meantime.

Thanks again...
S.

I think the NRF24 related quality of Nicks code is pretty low.

It seems he had to struggle with the original maniacbug library
and ended up with some very strange "voodoo quality" code.

Like:

  radio.startListening ();
  radio.powerDown ();

Test whether begin works better than powerUp,
but check the timing requirements for your uncommon state transitions.
IIRC it takes quite some time to reach standby from powerDown.

His code is weird for sure. I noticed that odd construction, and also:

  radio.startListening ();
  delay (10);
  radio.stopListening ();

which just seems bizarre. (Maybe the equivalent of banging on the TV to fix reception?) His code also explicitly manipulates the CE and CS states. "Voodoo" is a great way to describe it. Makes me wonder if there is a version-specific bug in the RF24 library.
Thanks as always for the feedback.
S.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.