Sudden extreme battery drain [SOLVED]

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.. :-)

Sudden extreme battery drain [SOLVED]

19

11.7k

11.2k

113.1k