Sudden extreme battery drain [SOLVED]
-
@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. -
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 -
did you try to run a clear_eeprom sketch from the mysensors examples? Or burn an optiboot bootloader?
-
@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 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.
@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.
-
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.@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 errorquote 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
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 errorquote 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."
-
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
-
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.
-
@gohan Ok. Then I will try your suggestion. I will first have to learn how to replace the bootloader.. :-)
@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
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@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?
-
@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?
-
@strixx you can use almost any Arduino. Instructions are available at https://www.arduino.cc/en/Tutorial/ArduinoISP
@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 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.