Project advice NRF24L01 network

Hi folks,
This is a general request for advice.
As you can see I’m part way through building this and I’m waiting for some hardware to be able to complete the project. My goal is to update here (if that’s appropriate) and gather feedback as i go.

My aim is to measure temperature in 5 different places and have these scrolled across an LCD display at the hub (Uno or Due on mains).
These units need to run from batteries, and small ones, too. So powering the board (3.3v Pro Mini) down is important
Code section 1 - run a sleep program to increase battery life -ACHIEVED

Section 2 - read a DHT 22 - ACHIEVED

Section 3 - Send readings via an NRF24L01 to the hub - Waiting for Hardware. I’ve been leaning on this Nrf tutorial pretty heavily. Still feel a bit intimidated by this. Especially getting the different pipes set up, and I’m still researching this.

Section 4 - Check bettery life - If low ping a buzzer - Thinking and research - This seems fairly easy in code but the electronic set up seems more challenging

Section 5 - Maybe?? Use a watchdog timer to reset the board, plus reset the counter would replace parts of section 6.

Section 6 - Increase loop counter and reset - ACHIEVED

For sections 1, 4, and 5 I’m using Gammon's power article to help. But, I’ll tackle those once I have the NRFs up and running.

/*
  This is the testing area for the Temp transmitter.
  This sketch needs to:
  sleep for 8 seconds
  wake up and check how many times it has been asleep
  wake and complete the loop code (reading approx. every minute)
  read a DHT 22
  Send DHT data information back to the hub via NRF24L01
  This will be part of a network of 5 DHT sensors, one reciever and 4 transmitters
  reset the counter
  go back to sleep 
  

Code section 1 - run a sleep program for the desired amount of time to increase battery life. Multiples of 8 second sleep times -ACHIEVED
Section 2 - read a DHT 22 - ACHIEVED
Section 3 - Send readings via an NRF24L01 to the hub - Waiting for Hardware and Thinking and research
Section 4 - Check bettery life - If low ping a buzzer - Thinking and research - If works order more buzzers
Section 5 - Use a watchdog timer to reset the board and reduce hangs, plus reset the counter in the sleep loop
Section 6 - Increase loop number - ACHIEVED 

Design spec
Run on a 3.3v Pro mini
Fit in a 60x60x20mm vented housing
Power from single CR2032
Be one of 4 transmitters to one hub (hub also reads DHT 22 and displays all readings on 20x4 LCD (mains power)



  Paul Hoskins
  This code is complied from examples and other open source code, as such it remains open source
*/

// ///LIBRARIES//////
// In here for the power saving on the Pro Mini
#include <LowPower.h> 

// In here to read the DHT
#include <DHT.h> 

// In here for when i need the NRF in place
#include <RF24.h> 
#include <SPI.h>

//include wathcdog timer
#include <avr/wdt.h> //not using this yet will set up for a hang.

/////DEFINITIONS/////

// Set up the DHT
// the pin the DHT is connected to
#define DHTPIN 6 
// The type of DHT sensor
#define DHTTYPE DHT22
// initialise DHT setup
DHT dht(DHTPIN, DHTTYPE);

// pulled from blink no delay, can't get this to work using delay instead. me=noob
// set up for delay period to enable a good read. i want to delay the beginning of the loop and after the serial text
// Generally, you should use "unsigned long" for variables that hold time
// The value will quickly become too large for an int to store
// unsigned long dhtStarted = 0;        // will store last time LED was updated

// constants won't change:
const long interval = 1000;           // interval at which to read (milliseconds) - can't make this work - do i even need it?

//number tracker for loops
static int count = 0; //start count at 0
static long reading = 7; // loop 7, or a minute ish, before reading dht
int setBack = 0; // sets the count back to 0
int readBack = 7; // sets reading back to 7
int resetTrigger = 1440; // final version =reset every 1440 counts 


//Buzzer set up
const int buzzer = 9; //buzzer to arduino pin 9

void setup() 


{  // put your setup code here, to run once:
  
  Serial.begin(115200); //begin serial for debug
  dht.begin();//begin the DHT 22
  pinMode(buzzer, OUTPUT); // Set buzzer - pin 9 as an output - Note to self, go buy buzzer

} // end of setup



void loop()




{// start loop code here
  // unsigned long currentMillis = millis(); // set millis as variable - not using this as could not make this work in the code (remove?)
   
 //CODE SECTION 1 - sleep loop
 
if (count <= reading)

{// open if loop
  // puts the board to sleep for 8 seconds
  LowPower.idle(SLEEP_8S, ADC_OFF, TIMER2_OFF, TIMER1_OFF, TIMER0_OFF, SPI_OFF, USART0_OFF, TWI_OFF); 
}// close if loop



 else // This loop contains CODE SECTIONS 2 thorugh 4
{// Open else loop

//if (currentMillis - dhtStarted >= interval) //  could not make this work (remove?)
{ //  start if block
              // save the last time you ran the loop - could not make this work (remove?)
             // dhtStarted += 1000; //  could not make this work (remove?)
    //Read DHT
         float hCam = dht.readHumidity();// read humidity from dht 22 for Cam's room
         float tCam = dht.readTemperature(); // Read temperature as Celsius (the default) for Cam's room
                      delay(500); // gives time to read the sensor   
         //Increase the sleep number      
         reading = reading + 7; //increase reading number so it keeps looping

  //remove for final, or replace with a warning buzz
  if (isnan(hCam) || isnan(tCam)) // Check if any reads failed
{//start if block
      Serial.println("Failed to read from DHT sensor!"); //replace with buzzer ding
        tone(buzzer, 1000); // Send 1KHz sound signal...
        delay(1000);        // ...for 1 sec
        noTone(buzzer);     // Stop sound...
       /* 
        *  Think about adding a buzzer sound here as monitor won't be connected to final work
        */             
}//end if block
  
 //to check everything is reading-  remove later
  Serial.print(" Humidity: ");
  Serial.print(hCam);
  Serial.print(" %\t");
  Serial.print(" Temperature: ");
  Serial.print(tCam);
  Serial.println(" *C ");
    
    delay (500); // gives time to print the sensor info
  



//CODE SECTION 3 - Transmit data via NRF24L01
{
 Serial.println(F("Code section 3 NRF24L01 Module")); //So much information available it's a little confronting
 delay(50);
}// Close 3

//CODE SECTION 4 - check battery - Buzz if voltage low
{
 Serial.println(F("Code section 4 battery monitor"));  //Research https://forum.arduino.cc/index.php?topic=83978.0
 delay(50);
/*Buzzer loop code as above
 *   tone(buzzer, 1000); // Send 1KHz sound signal...
     delay(1000);        // ...for 1 sec
     noTone(buzzer);     // Stop sound...
 */
 
} //Close 4


} // close else block

//CODE SECTION 5 - Watchdog to reset board every 24 hours
{
 Serial.println(F("Code section 5 Watch dog timer")); //More research needed for this. Is it better than the counter
 delay(50);
} //Close 5
}

{// CODE SECTION 6 - Increase loop number and reset
   // increase the counter
   count ++; 
}
  if (count >= resetTrigger)
{
     count = setBack;
     reading = readBack;
     //Serial to monitor progress - remove before final 
     Serial.println("Reset loop");
} 
}//Close 6


//end of loop

As I don’t have a specific question, I errmd and arrd about posting because it’s difficult to comment, but please do comment constructively if you see things that could be done better.

Also, I know people don’t like delay, I tried using millis and it just sent everything crazy. I’ll look at this again before the final version, but it’s not a priority right now.

Thanks,

Cup

You use the word "network" in your Title. How far apart is the most distant nRF24 from the hub? If it is in wireless range of the hub then I would not see any need for the complications of the nRF24 Network.

Also it should be possible for all the communication to work with only a single pipe - but you need to provide details of the messages that need to be sent and how often they need to be sent.

In general it will be much easier to help if you ask a specific question.

...R

Hi Robin,
Thank you for your reply. You’re right, but I’m getting by with research and individual learning at the moment; however, I expect to run into issues and wanted a starting point. Also, at the moment the code I’ve written seems to function as intended, but I don’t know if there are any 'obvious' mistakes in it.

The longest run will be about 30m through the house, but that can be reduced if the 'network' struggles. The Hub will be either in the lounge or kitchen and each bedroom will have a sensor in. I use the word ’network’ as it is how I understand this concept. If you mean a chain of NRFs to get a longer range, I don’t think this will be required for the size. My apologies if this was misleading.

It was my understanding from the information that each communication channel would need to be its own pipe. If we have the Hub set to RX and then 4 other NRFs set to TX they are all on the same channel, each have an address on that channel, and each have a pipe to communicate with the Hub. This will be easier once I get the units and I can start working through the examples in the RF24 libs.

Information would be the data from the DHT22s and possibly battery level, too. As another way to indicate battery level on the Hub screen.

Thank you,

Cup

Iamacup:
It was my understanding from the information that each communication channel would need to be its own pipe. If we have the Hub set to RX and then 4 other NRFs set to TX they are all on the same channel, each have an address on that channel, and each have a pipe to communicate with the Hub. This will be easier once I get the units and I can start working through the examples in the RF24 libs.

Don't design the wireless system before you have a clear description of the messages that need to be transmitted and the intervals between messages. I find that a written description is a great help for my planning.

For example if you have 4 satellites sending to the hub and if the messages are sent occasionally whenever a satellite wakes up then they only need to send to a single address in the hub provided each satellite includes a byte in its message that identifies itself. To my mind that is much simpler than multiple pipes and multiple addresses.

Also keep in mind that an nRF24 has only a single wireless receiver so even if you are using multiple pipes it can only receive one message at a time and the same risk of data collisions exists. With or without multiple pipes you will need to ensure your code can handle data collisions - perhaps by each satellite holding off the repeat transmission for a random amount of time. Note that what I am talking about is when the normal nRF24 retry process fails.

...R

Okay, that’s heaps to think about. Back to the books me thinks.

thank you,

Cup