Under new management??

Posted by: @frogandtoad

@pugwash

I haven't checked that, but if you check out the previous reference I gave you, it will most likely cover how that IRQ works:

Have you by any chance checked out the following methods?:

void RF24::powerUp(void);
void RF24::powerDown(void);

RF24 class reference

Same link I provided last time 🙂

The radio will generate interrupt signals when a transmission is complete, a transmission fails, or a payload is received.

//Mask all interrupts except the receive interrupt:
radio.maskIRQ(1,1,0);

This could be quite useful if combined with LowPower.attachInterruptWakeup()

The following code change in setup() will facilitate a much cleaner start and be useful as a debugging aid:

  //Initialise the nrf24l01

  SPI.begin();
  radio.begin();  
  
  if(radio.isChipConnected()){    
    radio.setAutoAck(1, true);
    radio.setRetries(2,15);
    radio.setPALevel(2); // Options  are RF24_PA_MIN, RF24_PA_LOW, RF24_PA_HIGH, RF24_PA_MAX
    radio.setDataRate(0); // Options  are RF24_1MBPS, RF24_2MBPS, RF24_250KBPS
    radio.setCRCLength(2); // Options  are RF24_CRC_DISABLED, RF24_CRC_8, RF24_CRC_16
    radio.maskIRQ(1,1,0); // allow an IRQ when a message has been received
  }else{
    Serial.println("nrf24 module not found!");
    while(1);
  }

@pugwash

Great work, Steve!

Another little bit of information. After a little code change I discovered that these two sketches produce the same results.

Using .available to trigger the read() function:

  while (network.available()){ // Is there any incoming data?
    RF24NetworkHeader header;
    network.read(header, &myObject, sizeof(myObject)); // Read the incoming data
      
    // main code here....
    
    }

 Using the interrupt to trigger the read() function:

  if(LEDstate !=0){ 
    RF24NetworkHeader header;
    network.read(header, &myObject, sizeof(myObject)); // Read the incoming data
      
    // main code here....
    
    LEDstate = 0;
    
    }

@pugwash

Looking very good, nice and clean code too, but starting to get large too - Maybe some refactoring needed soon 🙂

Looking forward to seeing the overall savings you've made.  May be time to add an SD card to log to, so then you can create a spreadsheets with a chart reviewing how your climate has changed over time?

Great stuff!

[EDIT]

By the way... all those print statements take up a lot of dynamic memory, so f you start running low you might want to incorporate the "F()" function - You can save a lot of critical space - Here's an example of just one string:

Serial.println("DYNAMIC MEMORY HOGGING STRING");
// Sketch uses 1504 bytes (4%) of program storage space. Maximum is 32256 bytes.
// Global variables use 218 bytes (10%) of dynamic memory, leaving 1830 bytes for
// local variables. Maximum is 2048 bytes.

// Using the "F()" function wrapper with even longer string...
Serial.println(F("THIS IS A LESS DYNAMIC MEMORY HOGGING STRING"));
// Sketch uses 1530 bytes (4%) of program storage space. Maximum is 32256 bytes.
// Global variables use 188 bytes (9%) of dynamic memory, leaving 1860 bytes for
// local variables. Maximum is 2048 bytes.

We now got a 30 bytes saving on our dynamic memory, as much of it was now pushed over to the program storage space which is larger.

Cheers!

@frogandtoad

but starting to get large too 

I am glad you didn't say "bloated", then I would have been really insulted! ? 

By the way... all those print statements take up a lot of dynamic memory, so f you 

And fu2! ? 

Seriously, I discovered that F() only works on "real" strings, this was the compiler message before adding the F() function:

Sketch uses 14636 bytes (47%) of program storage space. Maximum is 30720 bytes.
Global variables use 1271 bytes (62%) of dynamic memory, leaving 777 bytes for local variables. Maximum is 2048 bytes.

And after adding the F() function:

Sketch uses 14724 bytes (47%) of program storage space. Maximum is 30720 bytes.
Global variables use 989 bytes (48%) of dynamic memory, leaving 1059 bytes for local variables. Maximum is 2048 bytes.

That is a considerable saving, and the sketch is still working.

And as for the power saving, the remote has been up for the last 72 hours and the voltage on the battery has only dropped from 8.5V before switching on to 7.6V approximately 72 hours later. This is a vast improvement compared to a 2V drop over 44 hours.

@frogandtoad

May be time to add an SD card to log to, so then you can create a spreadsheet with a chart reviewing how your climate has changed over time?

I am not going to bother with SD cards, but I may log results on a 256K EEPROM, I have about 10 of them lying around doing nothing, and then transfer the data to Matplotlibs in Python for visualisation of the data.

@frogandtoad

I think the next stage may be to get some PCBs rustled up! I want about 5 of these configurations.

And I will only be using ATmega328P chips, without all the peripherals, which will give me even more power savings (without the onboard power-on LED & USB chip etc.).

@pugwash

Posted by: @pugwash

I am not going to bother with SD cards, but I may log results on a 256K EEPROM, I have about 10 of them lying around doing nothing, and then transfer the data to Matplotlibs in Python for visualisation of the data.

Yes... that's a good idea too.... my idea wasn't necessarily to use an SD card, but the logging of the data for future analysis and presentation.

Cheers!

@pugwash

Posted by: @pugwash

I will only be using ATmega328P chips, without all the peripherals

Yep, good idea... why didn't I mention that! 😛
Looking forward to the updates!

@frogandtoad

Got the ATmega328p ICs on order along with a bootloader shield, and will also start replacing the Eneloop rechargeable blocks with 18650s, and try to reduce everything to 3.3V.

@frogandtoad

The results of the first test are in.

Just putting the ATmega128 to sleep and powering down the nrf24 have increased the battery life from 44 to 110 hours.

There is a lot more to get out of this, that's for sure!

@pugwash

Posted by: @pugwash

Got the ATmega328p ICs on order along with a bootloader shield, and will also start replacing the Eneloop rechargeable blocks with 18650s, and try to reduce everything to 3.3V.

Sounds good!

Posted by: @pugwash

The results of the first test are in.

Just putting the ATmega128 to sleep and powering down the nrf24 have increased the battery life from 44 to 110 hours.

There is a lot more to get out of this, that's for sure!

Wow, that's a huge increase already... can't wait to see how much more you squeeze out of it, well done sir!

Gonna check your code to see if I can do some refactoring, more from a readability and organisational point of view 😉

@frogandtoad

I don't see much room for code improvement on the remote sensors, and the local Nano is powered through the USB cable anyway!

My research has come up with the fact that the biggest and most useless thing on the Nano is the USB interface which I cannot turn off programmatically.

Stripping the remotes down to a bare ATmega328 chip is going to give me huge power savings up to a factor of 1000, as the Nano is still consuming 30 mA now and the bare chip sucks up only about 25µA at 3.3V.

I have checked that all the sensors work on 3.3V, the bare ATmega328 also, and is the reason I am changing the remote power supplies to 18650 rechargeables.

I could get months of uptime with this configuration.