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