Measured using this:
http://www.st.com/en/evaluation-tools/x-nucleo-lpm01a.html
so this is average over a half hour or so. Peak current is ~33 mA during LoRa Tx, of course.
Measured using this:
http://www.st.com/en/evaluation-tools/x-nucleo-lpm01a.html
so this is average over a half hour or so. Peak current is ~33 mA during LoRa Tx, of course.
you are probably not talking about the same thing.
the things node / the mentioned sketch / the TTN lib version / the rn2483 firmware version
Perhaps, and you’re right I didn’t read every entry here.
I am just asking a simple question.
When the TTNode is reading sensors and sending LoRaWAN Tx, what is the average current usage? I thought the answer was a few mA, maybe I misread the posts I did read.
If it is >> 100 uA, do you know and can you please explain to me why?
please read this topic first
The 1tx/10min ttn node is still running this morning and it says its battery voltage is down to
{“battery”:3280,“event”:“interval”,“light”:48,“temperature”:22.06}
{“battery”:3280,“event”:“interval”,“light”:53,“temperature”:22.06}
3.28 Volt. I am suprised that it is still running and has 285 messages sent starting with non full batteries at 3.498V. Will see if it still runs this evening…
When it dies I will start another test with new batteries and 1 message/hour
@HanspeterH
Very interesting testing, I think you should be able to go as low as 2.8V (all components can work) but that’s
depending on what BOD level TTN team have setup the 32U4 (may be 2.8V)
Anyway, I’m excited to see how low we can go,
@Charles, @BoRRoZ I did some investigation and found out the following things:
// This one is not optionnal, remove it
// and say bye bye to RN2983 sleep mode
delay(50);
@Charles can you add it?
3a. I disabled the Alert function of the temperature sensor
// TTN_TEMPERATURE_SENSOR.configureAlert(true);
TTN_TEMPERATURE_SENSOR.configureAlert(false);
// attachPCINT(digitalPinToPCINT(TTN_TEMPERATURE_ALERT), TTN_TEMPERATURE_FN, FALLING);
3b. I put the temperature sensor to sleep
void TheThingsNode::sleepTemperature()
{
//if (this->temperatureSleep || this->temperatureEnabled)
if (this->temperatureSleep) // changed by acht
{
return;
}
TTN_TEMPERATURE_SENSOR.setMode(MODE_SHUTDOWN);
this->temperatureSleep = true;
}
I am not quite sure, if my modification are good and “nice”, but it worked, after these modifcations the sleep current went down to 300uA
It looks like there is a switch to disable +UVcc, but I am not familiar with the Atmega world…
@Charles I would be glad, if you could check my code modifications and if okay issue the Pull request.
@BoRRoZ @Charles is it possible to disable +UVcc in code?
This would be perfect, than we would be able to reduce sleep current to 40uA only through SW fix.
Hey,
I’m following this topic for quite a while, to get my Node lasting longer.
Currently I am running the latest Cayenne Sketch from github.
Today, I was looking at my node in the dark, and found out, that the Green Led Blinks up once all 7-8 Seconds.
It is not bright, you can see it only in the dark if you look exactly.
Probably this has to do with the watchdog timer?
Wow!! Excellent observation. Never seen this until now
My ttn node is still running tonight, but its battery voltage reporting is strange. going from 3.3V to 3.292V for 8 transmissions to to 3.286V for another for another 8 messages (very normal behaviour so far) but then voltage goes down to 3.28V and stays at this value for the next 148 messages. This is the reported value… not sure if this is really true, because it does not make sense to me.I am going to measure the battery voltage with my DMM to see what the real voltage is…
Just measured: My DMM says 2.32V. So the reported battery voltage is WRONG!
I also saw the led flashing green with high frequency while it was probably trying to join
Strange enough but with 2.32V the ttn node is still sending messages, but always with same battery voltage value.Seems that some readouts of sensors start to fail when the voltage drops too far…
Or somewhere there must be a bug, either in HW or SW
Same at my Node, it sends the Voltage, down to 3,31V. Then the Voltage stays at this level.
When I measured with DMM, I got 2,9V … but at that point my node has stopped working at that point
@Acht, yes missed that one my fault, copy paste and forgot a line.
@Acht you got the USB vcc that the one consuming so much current, nice shot, and the wiring should have been like that
The datasheet mention the correct wiring
@sp1 yes this is the watchdog interrupt, the version I’m working on disable the watchdog on sleep (reducing again power) the wake up is done by lora module, stay tunned
I do not exactly remember what happens with low battery voltage. But there is a point, where light and temperature values become unreliable. Temperature locks to 16°C instead of 21°C. But it will still sending this value for a day or so with 5 minute interval. This was observed with ttn node library 2.0.2 without the actual power-saving optimizations.
Guys,
Hi just pushed a brand new version of the library. Before subimiting a PR to @johan I would test a little more since I’ve made some deep sleep arrangement with IRQ.
I added a method to wake up the node by the RNxxxx LoRa module, avoiding watchdog wake every 8s
see new method configInterval here.
For now only BatteryMonitorLPP example has been updated to new method (you’ll see your wake callback is also called with a wakeReason
parameter)
You’ll see some led/debug in the code, for extreme low power remove them.
Library is here, if you want to test it it could be very cool so I can fix any bug.
off course @Charles … tnx for all your hard work
void configInterval(TheThingsNetwork *pttn, uint32_t ms);
Strange… the version is now back to 2.0.2 ??
My 1tn node is still running i.e. sending messages. It looks as only the battery voltage sensor is stuck at 3.28V since 242 messages sent. The value of light-, and temperature sensor readings look still ok. Also movement and button still working. DMM reading of Battery voltage follows this evening.But I think the node sketch should have code added which prevents sending normal messages when sensor readouts become unstable but insteads should send an indicator that battery must be changed. If battery voltage reading is the same for 12 readouts or so, then it could send hex FFFF instead of the read out value.Of course the decoder must be able to handle such values…perhaps 0000 would be better choice than FFFF…
Oh no… its still sending… the run down continues…
I had a similar observation while updating trough Arduino. I updated manually trough the zip file.
Correct, I forgot to merge back to my fork the 1st merged part by @johan before commiting my changes, I won a conflict, it’s now solved. I definitively need to learn and work with branches
Since my firs time playing with conflict, just tell me if you have any issue
How recognizable. Github and I are not really “friends”.