1

Am working on a WiFi based irrigation system that utilises the RF24 lib for comms. Have got prototype of remote sensor up and running which has a standby current of 0.036mA and transmits data every hour using around a peak of 12mA. While running the prototype I see various retry attempts which seem to vary with every transmission – despite the setup being under the same conditions all the time. I have coded a retry loop to limit this to 10 tries connecting to the master – don’t want the sensor to continuously be sending without getting a confirmation from the master

What I am trying to find is the ideal delay required between various RF24 commands to limit transmit times as much as possible to conserve power usage. Any ideas?? (code snippets attached)

   pinMode(mostureSensorVCC, OUTPUT);
   digitalWrite (mostureSensorVCC, HIGH); //VCC to sensor   
   pinMode(mostureSensor1, INPUT);      //moisture sensor on
   delay(10); 
   int sensorValue1 = analogRead(mostureSensor1); // read the input on analog pin 
   Serial.print("Current Value Sensor 1 is : "); // debugging
   Serial.println(sensorValue1); // print out the value you read:  
   msg[0] = sensorValue1;
    digitalWrite(mostureSensor1, LOW);
    digitalWrite(mostureSensorVCC, LOW);    
      while (message != sensorValue1)
        { 

          Serial.print("sensorValue in while loop is "); // debugging
          Serial.println(sensorValue1);                   // debugging
          Serial.print("Message One is ");                // debugging
          Serial.println(message);                        // debugging  
          radio.powerUp();
          delay(70);

          radio.stopListening();
          delay(50);
          radio.write(msg, 2);
          delay(40);
          radio.startListening();
          delay(50);

         Serial.println(d);               // debugging


          if (radio.available())
            {   
             Serial.println("Radio available");     // debugging
              radio.read(msg, sizeof(msg));
              message = msg[0];
              Serial.print("Check Message received from master ");// debugging
              Serial.println(message);

            }
            if(d>=10)
            {
              Serial.println("Unable to send to master");
              break;
            }
       d++;   
  }

delay(1000);       
radio.powerDown();
message = 0; 
msg[0] = 0;
  • Do you eventually get confirmation after a number of tries? What state (power saving and all) is the master in when the node is starting to transmit? And what makes you think delay (or lack therof) is the cause? Did you try to adjust transmit power and data rate instead? – sekdiy Mar 18 '16 at 9:31
  • 1
    1. Don't use delays, totally unnecessary 2. Look at the examples, PingPair etc. – Avamander Mar 18 '16 at 12:47
  • Hi, Thanks for the great responses Get confirmation after different numbers of replies – ranges from 2 to 8 or 9 attempts to the master. Have seen on the master that it occasionally receives upto 3 messages which it seems to respond to. Will include relevant code clip from master below – Chris Muppitt Mar 19 '16 at 22:09
  • I have configured a specific channel outside of most used in my area, and have used recommended settings for remote sensor transmits //.....start radio and pipes..... Serial.println("Start radio..."); // debugging radio.begin(); delay(30); radio.setPALevel(RF24_PA_MAX); radio.setDataRate(RF24_250KBPS); //Fast enough.. Better range radio.setChannel(108); //2.508 Ghz Above most Wifi Channels radio.openWritingPipe(pipes[0]); radio.openReadingPipe(1,pipes[1]); – Chris Muppitt Mar 19 '16 at 22:13
1

Remove all delays except the one after startListening.

You could replace it with a "wait for radio.available to be true OR 50ms to have passed" piece of code. There is no need to wait for 50ms if the message was already received after e.g. 10ms.

Even better would be to use the ACK-package feature of the NRF. With this feature the master already prepares a package for the slave. Then when the slave sends it's message (every hour), the prepared package is included in the ACK (acknowledgement) packet.

As to optimizing it even further. It would be better to optimize the sleep code, then the send code. The sleep part will still use more power in an hour than the sending code, even if it takes 10 second to do so.

As to the lost packages. Try using a different channel. You also might want to get an NRF module with an real antenna, and maybe even an amplifier, for the master.

PS You can remove the serial.print in the deployed version.

  • Hi, Thanks for the response. Not sure how to configure ACK package feature – pretty new to this radio stuff. Have ( I feel) got the sleep code pretty well configured – drawing around 0.035mA while sleeping which works for me All of the Serial.Print statements are just for debugging and I do remove them from the deployed code. – Chris Muppitt Mar 19 '16 at 22:21
  • Also check out this battery calculator to see how much runtime you get. – Gerben Mar 20 '16 at 12:47

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.