should be the same in 0.0.5
LoRaWAN.Sleep();
Awesome Thanks!, so I dont need to do any other power management 
At the moment it looks like its consuming 0.019Ah and I think that is a little high. Im trying to get the 2 X 2500mah cells to last 2 years and I cant add solar to the unit.
Im still using 0.0.4 at the moment.
I assume you mean 0.019mA?
My application averages out at around 65uA with a PIR module drawing 25uA or so.
that would give you ap[rox 11days on battery.
is the amg really so power hungry?
i have the devboard with an bme680 sensor on a 3300mAh LiPo running for 3 weeks and the voltage did not noticeably dropped. and the bme680 is not very energy efficient
I must be doing something wrong as that was without the AMG being read. just the LoRa when that reading was taken. The AMG’s power consumption is prety low. on a full read and setup cycle it was pulling under less than 5ma and the time taken to set up and read the sensor without using its sleep mode was just above 200ms. that is with all pixels and the thermistor.
Over the weekend I will try and add the sleep function and see how that works as an alternative, it may be faster with the power consumption at 0.2ma and a read time of 50ms.
It seems to be a little more power hungry than the MLX sensors but it works on the CubeCell with minimal alterations to the library. I had no luck with getting either of the MLX sensors working on the cubecell I suspect due to the I2C speed issues.
@vangalvin You’re using the dev board? Are you measuring it with USB active (even if you unplugged after startup, it’s still active), that’d be an established cause of higher current drain.
Also be aware that LowPower_Handler() cycles through (I assume) a state machine and it takes multiple calls to get to the deep sleep mode, as documented in some comments in the code. I don’t know what’s going on under the covers, but ensure your state machine e.g. the example code one, lets that repeated cycling occur without re-waking everything.
Yes, I am at the moment using the dev board. So after pulling the USB the power needs to be cycled in order for the USB not to fire up?
I think i may have found one of the issues, when you trigger the LoRaWAN.Sleep(); the system does not seem to go in to sleep mode and contiues to run the DEVICE_STATE_SLEEP routine as well as continues to run anyting you have in the main program loop.
If you however use a timer event to wake the board up then it actually stops running anyting in the loop and power seems to be reduced considerably.
You should probably post some code. Waht you describe is not my experience.
Agreed you need to show us the code and the behaviour in more detail. I note again that you’ll see multiple executions of the loop as it goes to sleep, and it’ll wake up again on scheduled radio sends too of course (which is also interrupt driven).
@vangalvin what you describe is normal as @bwooce
and is commented in the example code.
to go to sleep it will need some cycles.
Here is the sample code I am running, I have removed the AMG8833 libs and readings for the moment. At the start of the loop that line will print every cycle even when its in sleep mode. I would have thought that when it went in to sleep mode it would not print until the next wake cycle.
On the other example prior to using the LoRaWAN.Sleep(); and using the timer to wake up it seems to work.
#include “LoRaWan_APP.h”
#include “Arduino.h”
const char myDevEui[] = { 0x**, 0x**, 0x**, 0x**, 0x**, 0x**, 0x**, 0x** };
const char myAppEui[] = { 0x**, 0x**, 0x**, 0x**, 0x**, 0x**, 0x**, 0x** };
const char myAppKey[] = { 0x**, 0x**, 0x**, 0x**, 0x**, 0x**, 0x**, 0x**, 0x**, 0x**, 0x**, 0x**, 0x**, 0x**, 0x**, 0x** };
#ifndef LORAWAN_CLASS
#define LORAWAN_CLASS CLASS_A
#endif
#ifndef ACTIVE_REGION
#define ACTIVE_REGION REGION_AU915
#endif
#ifndef LORAWAN_NETMODE
#define LORAWAN_NETMODE OTAA
#endif
/LoraWan Class/
DeviceClass_t CLASS=LORAWAN_CLASS;
/OTAA or ABP/
bool OVER_THE_AIR_ACTIVATION = LORAWAN_NETMODE;
/ADR enable/
bool LORAWAN_ADR_ON = LORAWAN_ADR;
/* set LORAWAN_Net_Reserve ON, the node could save the network info to flash, when node reset not need to join again */
bool KeepNet = LORAWAN_Net_Reserve;
/LoraWan REGION/
LoRaMacRegion_t REGION = ACTIVE_REGION;
/* Indicates if the node is sending confirmed or unconfirmed messages */
bool IsTxConfirmed = false;
uint8_t ConfirmedNbTrials = 8;
/* Application port */
uint8_t AppPort = 2;
/the application data transmission duty cycle. value in [ms]./
uint32_t APP_TX_DUTYCYCLE = 60000; //15000;
extern uint8_t DevEui[];
extern uint8_t AppEui[];
extern uint8_t AppKey[];
/* Prepares the payload of the frame */
static void PrepareTxFrame( uint8_t port ){
digitalWrite(Vext, HIGH);
AppDataSize = 13;//AppDataSize max value is 64
uint16_t BatteryVoltage = GetBatteryVoltage();
AppData[0] = (uint8_t)(BatteryVoltage >> 8);
AppData[1] = (uint8_t)BatteryVoltage;
//AMG8833 Data Goes Here but has been removed for testing purposes.
//data1
AppData[2] = 0x10;
AppData[3] = 0x10;
//data2
AppData[4] = 0x20;
AppData[5] = 0x20;
//data3
AppData[6] = 0x30;
AppData[7] = 0x30;
//data4
AppData[8] = 0x40;
AppData[9] = 0x40;
//data5
AppData[10] = 0xF0;
AppData[11] = 0x0F;
//data6
AppData[12] = 0xA1;
AppData[13] = 0x0A;
}
void setup() {
memcpy(DevEui, myDevEui, sizeof(myDevEui)); //Add these 3 lines to setup func
memcpy(AppEui, myAppEui, sizeof(myAppEui));
memcpy(AppKey, myAppKey, sizeof(myAppKey));
BoardInitMcu();
Serial.begin(115200);
#if(AT_SUPPORT)
Enable_AT();
#endif
DeviceState = DEVICE_STATE_INIT;
LoRaWAN.Ifskipjoin();
}
void loop()
{
Serial.println(“anyting in here prints every loop regardless of sleep”);
switch( DeviceState )
{
case DEVICE_STATE_INIT:
{
#if(AT_SUPPORT)
getDevParam();
#endif
printDevParam();
Serial.printf(“LoRaWan Class%X start! \r\n”,CLASS+10);
LoRaWAN.Init(CLASS,REGION);
DeviceState = DEVICE_STATE_JOIN;
break;
}
case DEVICE_STATE_JOIN:
{
LoRaWAN.Join();
break;
}
case DEVICE_STATE_SEND:
{
PrepareTxFrame( AppPort );
//^^^ this turns on the AMG8833 and prepares the data
LoRaWAN.Send();
DeviceState = DEVICE_STATE_CYCLE;
break;
}
case DEVICE_STATE_CYCLE:
{
// Schedule next packet transmission
TxDutyCycleTime = APP_TX_DUTYCYCLE + randr( 0, APP_TX_DUTYCYCLE_RND );
LoRaWAN.Cycle(TxDutyCycleTime);
DeviceState = DEVICE_STATE_SLEEP;
break;
}
case DEVICE_STATE_SLEEP:
{
LoRaWAN.Sleep();
break;
}
default:
{
DeviceState = DEVICE_STATE_INIT;
break;
}
}
}
I have a theory about this. If you’re printing a long string at the head of the loop, then I’m guessing the serial transmit handler will be generating interrupts, and this may stop the device falling asleep properly.
I removed the println and you were right, this made a huge difference. Then after flashing I power cycled the cubecell and by doing so the power consumption of the above code has come down to 0.00109mah 
that’s with with updating TTN every minute.
Now to stick the AMG code back in. I never would have thought about the USB not going on to low power mode after the plug was pulled. I think once I get this in to a production state with its own board I may look at connecting pins 11 and 12 to force the CP2102 in to suspend mode.
Thanks for helping out with that guys!
B
Glad to help. How are you measuring the power consumption? And do you mean 0.00109mA? Because that’s 1.09 uA, which sounds way too low. Maybe you have an extra zero in there somewhere.
I’m using a Wireless Shell set up with an INA219. Checked the settings with the meter in respect to the voltage across the shunt, and put a meter inline with the battery to confirm the readings.
and Sorry you were correct. that was 0.00109 Amp/Hour.
There is going to be some error in this given the INA219 is not well suited to measuring micro currents but its giving me a reasonable estimation at the moment and seems to be comparable to what i’m getting on the meter.
Sorry, but 0.00109 Amp/Hour makes no sense.
Anyway, I looked up the INA219, it has a resolution of 800uA. Since the CubeCell is supposed to run at tens of microAmps or less, it is not really a good tool. Added to which, the CubeCell will take the best part of 100mA when transmitting… All in all, the INA219 is probably not the best solution.
I used a Sparkfun coulomb counter PCB and changed the sense resistor to 0.2 Ohms. Still not ideal, but better than INA219.
I do like the Coulomb Counter! I may ordeder one in to add to my test bits.
Im kind of surprised that over the years no one has build a nice little kit that you can connect your battery to, connect the devcie and log the power usage over time to get an idea of how log the battery will last in a real world enviroment.
I had to change the resistor on the INA219. I may just bite the bullet and bild an opamp and use the scope to track the current consumption.
The other measurement option that I haven’t yet pushed the button on is the EEVBlog’s uCurrent or the (newer) CurrentRanger
hehe, Funny you should say that. I have been looking at the same thing but sparkfun disscontinued it.
Hmm, even the Scope is reading lowe levels than i would have expected.
Using a 0.1 Ohm
Sleep mode is showing 0.058mv
Reading the sensor is 0.132mv
LoRa transmission is only 1.78mv
I do have the gateway sitting nearby in the same room and stuck a 30dBi attenuator on the antenna but that should not make too much of a diference.
Checking the battery voltage is also interesting. Battery was charged to 4.017V. over the last 12 hrs its dropped to 4.006V on a 900mah battery.
It would be so nice to have a device that you could just plug in, dial up your battery size and voltage then let it run and estimate the runtime of the system.
Its intersting looking at the process on the scope. on wake there is a BIG spike in power. I suspect this is the sensor surging. Then the read cycle.
But here is the really funky one, Big surge, read sensors, transmit the data then some weird glitches that look like an echo evey second after that that seem to deminsh
This is reading the power side because I was tryinhg to work out where I was going wrong with the power readings.
