Dear Robert, @robert-hh said in G01 power consumption: Without LTE init, the current drops to 20µA too. Are you saying that the LTE shutdown magic by invoking lte.deinit() referenced many times in the forum will not be required at all? Our scenario is that we are currently not using the LTE modem of the FiPy and want to get power consumption as low as possible. We are humbly asking for your experience here, especially with the latest firmware releases. Also, I just stumbled over lte.send_at_cmd('AT!="powerOff"'), which also does not sound that bad ;]. Maybe this will shut down the modem in the quickest way possible without going through all procedures of the regular lte.deinit(). Thanks already for taking the time to answer our question on this evergreen topic. With kind regards, Andreas.

@spiderplant0 Hi, I can't speak to the specifics of your case--I'm using a bare GPy sitting on a custom board--but I've also been looking into deep sleep current consumption. I started a thread on the GPy board, where you can see my tests and results, but the short version is that with all the networks/peripherals down and doing a machine.deepsleep() the best I've gotten is also around the 0.5mA mark. This is a total guess, but it looks very similar to doing a deepsleep() rather than actually "pulling the plug" as that shield seems to allow for.

@tom You should probably instead do the following set socket to blocking send set socket to non-blocking receive save config Otherwise you actually try to receive, save, and deep sleep before the packet has actually been (completely) sent. An alternative is to add a manual sleep, but remember that the time between send and receive is variable (the network can change the RxDelay).

Ah ha. I was using the wrong interrupt script. This is the correct working code for an accelerometer interrupt (P13) of machine.deepsleep(): import machine machine.pin_deepsleep_wakeup(['P13'], machine.WAKEUP_ANY_HIGH, False) machine.deepsleep(10*1000) So for pin interrupts there is a callback() function to create interrupts of active and sleep modes but the pin_deepsleep_wakeup() is needed to interrupt deep sleep (is that what you meant by "wake-on-pin" @jcaron?). There is no interrupt handler for pin_deepsleep_wakeup() because the working memory is cleared after deep sleep (as mentioned by @jcaron below). @jcaron I had tested my interrupt handler without sleep and it did work. In my main.py I had the following script to test that it woke from deep sleep and ran main.py. import pycom import utime pycom.heartbeat(False) #turn off LED pycom.rgbled(0xFF0000) #red LED utime.sleep(2) pycom.heartbeat(False) #turn off LED

@alexpul if you want low power it’s going to be one of the last two. On a WiPy 3 the recommended option is machine.deepsleep, though I haven’t checked whether it can be used with wake-on-accelerometer. You probably won’t be able to capture the acceleration at the actual time it is over 3g, though, it takes a little while for the WiPy to wake up...

@Erick-Falcon Why did you post that here? It is not related to the topic.

As of last week, I cannot reproduce the error anymore... . If I encounter the issue again, I will write here again.

I have the same problem with some of my GPY. You are powering the GPY with 5V? Cumps,

@tschili Imho, if you trigger the wake-up just when the transmission starts, you'll have the issue that the GPY needs to little bit of time to wake-up and initialise, and you will most certainly lose and data received during that time. So you would need the SIM800L to wait until the GPY is ready to receive before it start sending the data, and some other way to wake up the GPY.

@jcaron Of course!

@jcaron @jubbs I used my administrative powers to update the above post adding the correct code tags.

The most recent post concernign ULP is here: https://forum.pycom.io/topic/7026/ulp-testing-pycom-firmware-with-ulp-support. From what I know we're still interested in implementing this feature, but again, we're interested in implementing a lot of features, with only limited time :)

@jcaron Thanks a lot for the explanation! That solved the question for me.

You have to look at machine.deepsleep link text For example with machine.deepsleep(60000) the LoPy will sleep for 60 seconds (better to say about 60 seconds).

@akshayjames I think the problem is the button on the Pysense goes low when pressed, not high, so you want to wake up on low.

@Andy_N said in Power consumption / wifi-information storage machine.deepsleep(): OSError: the requested operation failed We just mitigated this through [1] by invoking lte.deinit() with the "reset" operation like lte.deinit(detach=False, reset=True) [1] https://github.com/hiveeyes/hiveeyes-micropython-firmware/commit/ec7c80e1219fb119c2881a0019cecdfad220f29f