FiPy + Expansion Board: Battery Question

[securigy]

*@robert-hh With regards to DeepSleep:
I read some postings on the subject, including yours:
jcaron Nov 30, 2018, 2:43 PM
@james-matthews just to clarify, deep sleep achieves very low power consumption by powering down nearly everything on the chip, including the cores and all associated state (registers) and RAM.

So once it exists deep sleep, it doesn't remember a thing, and it has to start from scratch again, so you need to maintain any state you need across sleep in long-term storage (if you need any state at all).

robert-hh Nov 30, 2018, 4:16 AM
@james-matthews when the device wakes up from machine.deepsleep(), runs through the reset stages. So you cannot simply put deepsleep() into a loop like you would do with sleep(). Before deepsleep() you have to save your execution stage, after reset check the reset cause, and then resume the state you code had before deepsleep().

nespressif Nov 30, 2018, 3:42 AM
Hello @james-matthews , I don't know exactly what you want to do, but deep sleep is always used as the last function of the program, that is, you do what you want and as last instruction you put machine.deepsleep(300000). Your code will run and then the module will sleep for 5 minutes, when that time ends will be restarted and run again from the beginning, ie reset.*

I must admit I am bit surprised by this - it is about "reset" do I understand correctly that if I put FiPy into deep sleep of 5 seconds at the end of the code, then after 5 seconds it completely resets like a "reset-button reset" and the execution of my MicroPython script will start from the beginning like loading libraries, and will do all the LTE initialization, lte.attach, I2C setup, and GPS initialization, etc ??

So again surprised to read the "reset" thing and if this is correct that after deep sleep the modem resets and the entire micropython script executes from the beginning (and it indeed takes 30+ sec to init and to attach the LTE modem) and I'd like to deliver GPS reading every few seconds - then the Deep Sleep it is not a viable solution at all... Am I correct?

[securigy]

@robert-hh I see - I thought initially that there is some add-on in VS Code that produces the chart without all the logging, etc...

[securigy]

@robert-hh Word of caution - I guess I did not read well enough - just got it from Amazon and it has USB Type C on both ends. So now, I am waiting to USB-Type-C to USB-Micro-B adapters....

[robert-hh]

@securigy said in FiPy + Expansion Board: Battery Question:

I thought initially that there is some add-on in VS Code that produces the chart without all the logging,

No. But using logging and Excel is not that much work. And since the data has to be corrected anyhow, it is not an additional work.

and it has USB Type C on both ends

I considered getting that device, but this USB-C stuff stopped me. The other drawback: It is promising more than it can deliver. The 6 digit display seems to tell, that there is a current resolution of 10 µA. The data specs (https://www.amazon.de/gp/product/B07P2J5VTT?pf_rd_p=8997cce2-05c4-4359-bdb7-10e52332d836&pf_rd_r=Y0QG8QTTX7CEF8YRMEV8&th=1 ) however say, that the error is 0.1% +/- 10 digits (or 0.5% +/- 10 digits for voltage). That means, that the last two digit in the display just shows noise and the real resolution is not better 1mA. That would be OK too, if true. For 6 digits the analog section in the measuring path would require -120dB noise margin, which is a huge challenge. So even from that aspect the specs look too god to be true.

[securigy]

@robert-hh I resolved Type C with this (arriving tomorrow). 4 adapters for $6.

All this playing with measuring current is great but I still have very principle question that is crucial to my development:

• So far from different posts I understood that once I put FiPy into deep sleep and the timeout expires the FiPy not only does not remember at what stage it was executing but is also is reset and starts the execution of the micropython from the very top. Now, I would not mind that, except that LTE initialization and attach() takes time - could be a lot - 30-45 sec. That means that if I want to push GPS coordinates to the Cloud over LTE-M every few seconds - I cannot since it takes LTE 45 sec to become operational. Is that my imagination or is it correct?

[robert-hh]

@securigy Your assumption about the LTE startup times is correct. The ESP alone take 2-3 seconds to boot.
If you want to transfer coordinates every few seconds, then the device has to stay powered. I have here a set-up with an generic ESP32, microypthon.org firmware, and a SIM7020 LTE module. The runtime current consumption is ~50mA. At lightsleep it decreases to ~30 mA, not even trying to let the LTE modem sleep. You might also ask @danielm, who made such a board in an attempt to have a reliable low power LTE solution. I do not know how far he got.
But you have to bear in mind, that the transmission energy does not come for free. So that power peak will always be there. Only startup times and standby current can be tailored.

[securigy]

@robert-hh Got it. Thank you again for this confirmation... I will take a look at SIM7020. I have been doing C/C++ for decades and C# the last nine years, but somehow I am really fond of this primitive puppy MicroPython - never wrote a firmware before with C... so it will be a factor...

[jcaron]

@securigy indeed as things stand waking up from deep sleep every few seconds is just not a possible scenario.

For the LTE side of things, that’s where PSM/eDRX should come into play. They allow the modem to be in a low power state but still be considered connected to the network, so when you have something to send you just wake up the modem, send, and put back the modem in low power mode. However IIRC (never tried it myself, but saw discussions on the topic) there are still issues with this in the FiPy. Note that even if supported by the FiPy, it also needs to be supported by the network, I’m not sure this is available everywhere.

Also, to send a position every few seconds, your GNSS chip will need to remain in a relatively high power state as well. Depending on the chip and what accuracy and interval you need there may be power saving modes, but it’s always a compromise, reducing power will mean reduced something else (nothing comes for free).

An alternative is to make sure you send data only if you actually move, do you can remain in deep sleep when the device is idle. You can use an accelerometer to wake up, or a vibration sensor. There are challenges with this as well, see relevant discussions on the forum (there was one on this topic a few days ago).

[robert-hh]

@securigy I just tested a generic ESP32 with the WiPy3 pycom firmware. The standby current is 35 mA, going down with machine.sleep() to 4 mA, including the USB/UART bridge. That is a very good figure! machine.sleep() keeps the machine state, so wake-up is immediate.
With an FIPY, the current at machine.sleep() with LTE enabled stays at 100mA, while teh ESP32 alone consumes almost no power at sleep().

[securigy]

@jcaron You are absolutely correct on all points: I jest read yesterday that ESP32 has ULP (Ultra Low Power mode) so it makes sense that FiPy will have something like that as well... another field for me to research. But for now I assume that I will not be using deep sleep.
About detecting motion: really good point - however my FiPy sits on Expansion Board 3.1 that I believe does not have accelerator...another hurdle...

Meanwhile, I did discover something useful that will allow me to experiment with mAh consumption with ease.
Check this thread:
https://forum.pycom.io/topic/5694/measuring-amperage-consumption

BTW, I am using GNSS Click 5 from uBlox with NEO-M8N with cold start of under 30 sec.