Sudden extreme battery drain [SOLVED]

[Strixx]

Hello!

I have a problem with extreme battery drain on one of my nodes. It's a temperature sensor with a DS18B20 and (NRF24 radio). It sleeps for 15 minutes and only reports temperature if changed more than 0.5 degrees. But at least one time per hour.
Have have two identical nodes with same sketch (except the name).
But one of them started to drain the battery. A pair of new batteries is drained in only 12-14 hours.

It was working fine for a couple of weeks. But about 2 weeks ago one of them stopped sending. I noticed this a day of two after I changed the location of the gateway. So I thought it was because of radio shadow.
But then a couple of days ago I went for changing the location of the node. And noticed that it was the battery that was dead. So I changed batteries and moved the sensor at the same time.
The next morning I noticed it was offline again.

So today I took it apart and start checking. Battery dead again. I have been checking cables now I can't find anything that should be causing this.

So before I upload the sketch again to the code I would like to here what you guys think.
Can it be a bug that I should try to find before doing that?

[gohan]

Start narrowing down the problem: while the node is sleeping start unplugging the radio and measure current, if it doesn't drop unplug the sensor and check current again. Or you could start by replacing the arduino and measure current. You should be aiming at less than 10-15uA

[Yveaux]

@strixx It could be that the relocation of the gateway made it extremely hard for the node to reach the gateway. Old versions of the library handled this 'sub-optimal' which could lead to excessive retries, depleting the battery. Which MySensors library are you using?
Try reverting to the old situation (locations of gateway and node) and see if the node behaves normal again.

[bjacobse]

Try to swap the NRF24L01+ modules and check if the current drains follow the radio module

[Strixx]

@gohan Done that now. The current doesn't change when unplugging the radio or the sensor. My very simple meter shows 67 mA when the node power up, and then it drops to 47-48 mA and stays there.
The node works, and sends data to the gateway.

[Strixx]

@yveaux I use version 2.2.0 of the library. And it does not help to move the node next to the gateway, it still drains the battery.

[Strixx]

@bjacobse Changed the radio to a new, but it is still the same.

[gohan]

if current stays at 47mA then I'd say it is not sleeping much

[Strixx]

So, as you see I have tried all of the suggestions. The node is working. Reporting to the gateway. The sensor connected to the arduino is working, and nothing wrong with the radio.

So can it be that some how the node doesn't sleep any more, and could this be because it had trouble to connecting to the gateway, and that something got stored in EEPROM that now prevents it from sleeping, even though it now can communicate with the gateway?
IS there someway I can find this out without uploading a new sketch to the node?

I am asking because I would like to help finding eventual buggs. It would be a missed opportunity if I upload a new sketch and that fixes the problem. Then we would not be able afterwards to find what was causing this.

[Strixx]

I have checked the code in the sketch. And I think that I have been mixing some code in all my sketches.
And it looks like the node is requesting acknowledgement from gateway, but I am not shore.

Is there a way to check this? To see if I have uploaded the wrong sketch?

And if that is the case. Can that be the cause for the battery drain?
The strange thing is as I wrote above, that the node doesn't seem to go to sleep even after I moved it to the same room as the gateway. It should be receiving ack from the gateway now. And the gateway is receiving the messages.
And the node has been working just fine until I moved the gateway, but now it is not. Not even after moving the node to the same room.

[gohan]

post node code and debug, also gateway debug when node conntects

[Strixx]

@gohan Well. I see that I was not clear about my misstake. I don't know which sketch I have uploaded to the node. I have several version of the sketch on my computer and I am not sure which I have uploaded.
What I do know is that none of them has enabled debug for serial output. I disabled that when I got them working.
So the only thing I can (at least that I know of) is checking the gateway log with MYS Controller. And i will try that tomorrow evening when I am back home from work.

And just to be cleare. I am asking for your help beacuse I want to help find an eventual bug in the library code.
I am happy with trying to upload a new sketch to see if that helps. But before that I want to know if there is any possible ways to find out why it doesn't go to sleep any more.

[gohan]

I think you need to upload one of the sketches you have and enable debug, otherwise we could only guess

[Strixx]

So now I have been investigating some more. I tried to upload my own sketch again, but that made no difference. The constant power consumption was still there. So I then took the example code from the homepage and did some small adjustments and tried again.
It still consume power even when sleep. But now my meter only shows a constant 26-28 mA.

Here is the code that I use now:

#define MY_DEBUG  // Enable debug prints to serial monitor
#define MY_SPLASH_SCREEN_DISABLED  // Save memory
#define MY_SECURITY_SIMPLE_PASSWD "secret"  //Simpel soft signing with password
#define MY_SIGNING_SOFT_RANDOMSEED_PIN A3  // Unconnected analog pin for random seed
#define MY_RADIO_NRF24
#define MY_RF24_CHANNEL 110  // Set the frequency to channel 110 (2,510MHz), to prevent interference with all available WiFi channels (ch 14 -> 2,495MHz)


#include <SPI.h>
#include <MySensors.h>  
#include <DallasTemperature.h>
#include <OneWire.h>

#define ONE_WIRE_BUS 3 // Pin where dallase sensor is connected 
#define MAX_ATTACHED_DS18B20 1
unsigned long SLEEP_TIME = 30000; // Sleep time between reads (in milliseconds)
OneWire oneWire(ONE_WIRE_BUS); // Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
DallasTemperature sensors(&oneWire); // Pass the oneWire reference to Dallas Temperature. 
int numSensors=0;
bool receivedConfig = false;
bool metric = true;
// Initialize temperature message
MyMessage msg(0,V_TEMP);

void before()
{
  // Startup up the OneWire library
  sensors.begin();
}

void setup()  
{ 
  // requestTemperatures() will not block current thread
  sensors.setWaitForConversion(false);
}

void presentation() {
  // Send the sketch version information to the gateway and Controller
  sendSketchInfo("pool", "2.2");

  // Fetch the number of attached temperature sensors  
  numSensors = sensors.getDeviceCount();

  // Present all sensors to controller
  for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {   
     present(i, S_TEMP);
  }
}

void loop()     
{     
  // Fetch temperatures from Dallas sensors
  sensors.requestTemperatures();

  // query conversion time and sleep until conversion completed
  int16_t conversionTime = sensors.millisToWaitForConversion(sensors.getResolution());
  // sleep() call can be replaced by wait() call if node need to process incoming messages (or if node is repeater)
  sleep(conversionTime);

  // Read temperatures and send them to controller 
  for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {

    // Fetch and round temperature to one decimal
    float temperature = static_cast<float>(static_cast<int>((getControllerConfig().isMetric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.;

    if (temperature != -127.00 && temperature != 85.00) {

      // Send in the new temperature
	  send(msg.setSensor(i).set(temperature,1));
	  Serial.print("Temperature sent: ");
      Serial.println(temperature);
    }
  }
  Serial.println("Sleep");
  sleep(SLEEP_TIME);
  Serial.println("Back from sleep");
}

And this is the serial output:

0 MCO:BGN:INIT NODE,CP=RNNNA---,VER=2.2.0
4 MCO:BGN:BFR
65 TSM:INIT
65 TSF:WUR:MS=0
73 TSM:INIT:TSP OK
75 TSF:SID:OK,ID=2
77 TSM:FPAR
114 TSF:MSG:SEND,2-2-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
413 TSF:MSG:READ,0-0-2,s=255,c=3,t=8,pt=1,l=1,sg=0:0
417 TSF:MSG:FPAR OK,ID=0,D=1
2121 TSM:FPAR:OK
2121 TSM:ID
2123 TSM:ID:OK
2125 TSM:UPL
2129 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
2136 TSF:MSG:READ,0-0-2,s=255,c=3,t=25,pt=1,l=1,sg=0:1
2142 TSF:MSG:PONG RECV,HP=1
2146 TSM:UPL:OK
2148 TSM:READY:ID=2,PAR=0,DIS=1
2152 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
2160 TSF:MSG:READ,0-0-2,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
2168 TSF:MSG:SEND,2-2-0-0,s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=OK:2.2.0
2179 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
3131 TSF:MSG:READ,0-0-2,s=255,c=3,t=6,pt=0,l=1,sg=0:M
3139 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=11,pt=0,l=8,sg=0,ft=0,st=OK:pool
3149 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:2.2
3158 TSF:MSG:SEND,2-2-0-0,s=0,c=0,t=6,pt=0,l=0,sg=0,ft=0,st=OK:
3164 MCO:REG:REQ
3168 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
3176 TSF:MSG:READ,0-0-2,s=255,c=3,t=27,pt=1,l=1,sg=0:1
3182 MCO:PIM:NODE REG=1
3184 MCO:BGN:STP
3186 MCO:BGN:INIT OK,TSP=1
3192 MCO:SLP:MS=750,SMS=0,I1=255,M1=255,I2=255,M2=255
3196 TSF:TDI:TSL
3201 MCO:SLP:WUP=-1
3203 TSF:TRI:TSB
3233 TSF:MSG:SEND,2-2-0-0,s=0,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:25.2
Temperature sent: 25.20
Sleep
3241 MCO:SLP:MS=30000,SMS=0,I1=255,M1=255,I2=255,M2=255
3250 TSF:TDI:TSL
3252 MCO:SLP:WUP=-1
3254 TSF:TRI:TSB
Back from sleep
3260 MCO:SLP:MS=750,SMS=0,I1=255,M1=255,I2=255,M2=255
3264 TSF:TDI:TSL
3268 MCO:SLP:WUP=-1
3270 TSF:TRI:TSB
3336 !TSF:MSG:SEND,2-2-0-0,s=0,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=NACK:25.2
Temperature sent: 25.20
Sleep
3346 MCO:SLP:MS=30000,SMS=0,I1=255,M1=255,I2=255,M2=255
3352 TSF:TDI:TSL
3356 MCO:SLP:WUP=-1
3358 TSF:TRI:TSB
Back from sleep

[gohan]

did you try to run a clear_eeprom sketch from the mysensors examples? Or burn an optiboot bootloader?

[Strixx]

@gohan Nope. But I tried that now, and then the sketch above again. Still the same.

[sundberg84]

@strixx if you removed sensors like suggested above and you still have a high mA you should try to change the pro-mini. It could be a failing capacitor leaking.

Your logs look fine.

[Strixx]

@sundberg84 Yes. I think I will have to do that.
I changed the test code above a little bit and added a delay for 5 seconds before sleep. And now I got better readings from my meter. It is about 48 mA when not sleeping and 28 mA when sleeping. So it does go to sleep but it is leaking somewhere.

To bad I don't have time this week for changing the arduino. I will have to get back next week about the progress.

[Strixx]

So. Forgot to get back.
But it was the Arduino it self that had gone bad. I switched the Arduino to a new, and everything was back to normal.

[gohan]

I had reports about switching to a different bootloader (like minicore) solved similar issues, as the stock bootloader sometimes doesn't like the sleep state

[bjacobse]

@strixx
so did you change the IC ATmega328P or was it the whole Arduino board?
if it's the whole Arduino board, then Sundbergs suggestion that a cap is faulty quite likely the error

quote Sundber84: "
sundberg84 Hardware Contributor 2 months ago

@strixx if you removed sensors like suggested above and you still have a high mA you should try to change the pro-mini. It could be a failing capacitor leaking."

[Strixx]

@bjacobse
Changed the whole board. I have it laying here in my workshop, but haven't got the time yet to investigate more.
It's shore sounds like @sundberg84 was right about a leaking capacitor.

[Strixx]

@gohan Well. I could try that. But it sounds strange to me that it will all the sudden change behavior. It was running fine without battery drain for a couple of weeks, and then all the sudden started draining the batteries.

[gohan]

I had a pro mini running fine for months in my outdoor solar sensor but I had to replace it as it was no longer working, with led flashing all the time. Later I managed to recover it by replashing bootloader and sketch again.

[Strixx]

@gohan Ok. Then I will try your suggestion. I will first have to learn how to replace the bootloader..

[bjacobse]

@strixx
Yes please try to update the bootloader first- I think it's quite interesting for the rest of us what is the actual rootcause
I don't use the stock bootlader in any Arduino codes, but instead an optiboot from GertSanders (as optiboot have enabled the WTD/watchdog)
https://forum.mysensors.org/topic/3261/various-bootloader-files-based-on-optiboot-6-2

[Strixx]

@bjacobse So it's time for a new raid with this project. I have been trying to read up on how to change bootloader. And if I understand it correct I need a programmer. And I only have a FTDI for uploading my code to my arduinos.
But somewhere I found that I can use a Arduino Uno instead.

So is this correct? If I buy a Uno will I be able to change to the new bootloader?

[mfalkvidd]

@strixx you can use almost any Arduino. Instructions are available at https://www.arduino.cc/en/Tutorial/ArduinoISP

[Strixx]

@mfalkvidd Thanks! Don't think I found that page before. Found a lot of pages about this subject but not this page. But if I understand it correct I still need to buy a new Arduino. I only have a big supply of Pro Minis. No other models.

[mfalkvidd]

@strixx a Pro Mini should work. It has the same mcu (atmega328) as the Uno, and pins 10-13 are available.

[Strixx]

So I have been reading up alot. And yesterday I finally managed to upload a new bootloader to this ProMini. It was the optiboot that @bjacobse linked to. All worked fine without any errors.

But I must have been doing something wrong, because I am not able to upload any sketch to the Arduino after that. I only get not in sync errors.

Unfortunately I don't have time to continue on this until late next week...

[Yveaux]

@strixx make sure you flash the correct bootloader for the crystal frequency of your pro mini (3.3V 8Mhz vs 5V 16MHz) and select the correct pro mini target in the Arduino IDE. Any errors will cause baudrate deviation in the serial bootloader communication, causing sync errors.