FiPy + Expansion Board: Battery Question
I am having FiPy v1.2 sitting on Expansion Board v3.1 and connection to GNSS development board via I2C and 3V3 and GND. How do I know what battery I need? How do I know if 3.7V Li-Ion battery with 2000 mAh be enough?
My GNSS dev board consumes 25 mA at acquisition and 22 mA at tracking (1 uA at standby).
More importantly, I read in Expansion Board documentation:
To use the battery, pull P8/G15 high (connect to 3v3). If you want to use the SD card as well, use a 10k pull-up.
Can anybody explain to me what are they referring to? (Pull p8/G15 high). Do they really mean that I have to connect this pin to 3V3 pin?
@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:
BTW, I am using GNSS Click 5 from uBlox with NEO-M8N with cold start of under 30 sec.
robert-hh last edited by 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().
jcaron last edited by
@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 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...
@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.
@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?
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.
@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 I see - I thought initially that there is some add-on in VS Code that produces the chart without all the logging, etc...
securigy last edited by 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?
@jcaron I did not follow that discussion either. But there seem to be no result. Maybe the new modem hardware works better in that aspect too.
jcaron last edited by
@robert-hh I don’t have a FiPy of GPy, but I wonder what became of the PSM/eDRX management in the modem? It’s supposed to provide a much quicker reconnection but I think there were still lingering issues last time this was discussed.
ad 1: I used the script you posted below. I replaced only lines 16-20 with a single line: "lte.attach(....)"
ad 2: I have a setup, where I measure the current using a INA219 breakout in the USB Vcc wire. I take a measurement every ~100ms, and print a ms timestamp and the current, which is logged into a text file. Then I import the text file into OO calc (like Excel), do the corrections of current and time offset. For every measurement I caculate the current * time_step, which gives an charge item, which is cumulated (integrated) into charge over time. Pretty basic.
ad 3: I measure the USB. But since I calculate the energy needed, that one is about the same for the battery connection. As part of the data correction, I subtracted the current used by the USB/UART adapter.
Some aspects have been found and criticized by other too, as you can find in this forum;
- The fipy takes some time to start and start-up the modem.
- Attaching after a cold boot takes considerably long. In the figure above this startup phase takes about 25 seconds. Other LTE modems are ready and attached within a few seconds.
- At about 42 seconds deepsleep() is called. Then it takes about 5 seconds with a short current burst until the device really sleeps. There may be problems with the LTE modem if you shut off power before this cycle ended. The Expansion board support a deepsleep method of cutting power to the xxPy device. While this results in the lowest current consumption, there seem to be side effects.
@robert-hh Couple of questions:
- Does your or jcaron's chart include disabling all other services/networks like BLE, WiFi, LoRa, etc...
- How do you produce this chart in the first place? tools? library?
- Are you measuring the USB input or specific wires?
robert-hh last edited by robert-hh
@robert-hh I took your script, modified it a little bit for my LTE place and recorded the current and charge in As. Diagram below. The total charge consumed was ~7 As at 5V -> Energy 35 Ws. At 2000mAh battery with nominal voltage has about 2 * 3.7 * 3600 = 26600 Ws. That means, that you can run about 750 of these cycles. If you run them every 5 Minutes + 1 Minutes operation time, that give a time of 4560 minutes or 76 hours (~3 days).
@securigy This current adapter is definitely the one on the market with the best resolution. The last digit shows 10µA resolution. So you can tell whther the current consumption is below 100µA. How precise that is, is to be determined.
When you use such a device, please bear in mind that due to the switching voltage regulator of the FiPy the current consumption at 3.7 V is higher than at 5V. The energy consumed (Voltage * Current) is about the same. So if the device takes 100mA at 5V, it will take ~130mA at 3.7 V.
@robert-hh The first this I started researching is how much current my whole assembly consumes... and I found the USB adapter that measures micro Amperes, or at least it says it does: (TC66 USB Tester)
@securigy The answer for supply is: do not run the device all the time. Set it to deep sleep when not needed. Then the power consumption is in the range of µA instead of mA.
Yes, you measure the current consumption with a multimeter.
Voltage is measure between 3V3 and GND. For measuring current you measure the wire through the + line of the battery.
For measuring the consumption on the USB connector there are convenient Adapters which you just plug in between. The only downside of these adapters is, that they do not have a µA resolution.
@robert-hh 8 hours... That's pretty bad. It is suddenly a critical issue for me that may prevent coming up with ANY portable solution using FiPy... So if I want to produce some kind of prototype/POC package in a standard Pycase box that last for 10 days then I need 72000mAh power bank which does not exist. The biggest are 30000 mAh and are very heavy and bulky relatively to Pycase... The 72000 mAh is based on 300 mA constant consumption which of course might not be the case... Whell, that means I have to invest more time in measuring and calculating and deep sleep...
So, here are the questions of non-EE guy:
- How do I measure the current consumption with multimeter? (I know benign question for mid-schooler) connecting multimeter to 3V3 and GND on the Expansion Board 3.1 ?
- Provided I have GNSS dev board connected with 3V3 and GND wires to 3V3 and GND pins on FiPy how do I measure total current consumption?
- Somewhere on this forum I saw following code. Is it conceptually the right thing to do in order to disable all other "unnecessary" services?
- Can anybody recommend high-density flat battery that will fit into Pycase?
import machine import network import os import time import pycom from network import LTE from network import WLAN from network import Bluetooth from network import LoRa # setup as a station lte = LTE() print("Line 15") lte.send_at_cmd('AT+CFUN=0') lte.send_at_cmd('AT!="clearscanconfig"') lte.send_at_cmd('AT!="addscanfreq band=28 dl-earfcn=9410"') lte.send_at_cmd('AT+CGDCONT=1, "IP", "telstra.internet"') lte.send_at_cmd('AT+CFUN=1') while not lte.isattached(): print("Attaching...") time.sleep(0.1) print("Attached") lte.connect() while not lte.isconnected(): print("Connecting...") time.sleep(0.1) print("Connected!") time.sleep(2) quit = False while quit == False: try: lte.deinit() except OSError: print(' Exception occured, retrying...') pass else: quit = True print("Disconnected") print('Switching off WLAN') wlan = network.WLAN() wlan.deinit() print('Switching off Heartbeat') pycom.heartbeat(False) pycom.rgbled(0x000000) print('Switching off Server') server = network.Server() server.deinit() print('Switching off Bluetooth') bt = Bluetooth() bt.deinit() print('Switching off LoRa') lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.AU915, power_mode=LoRa.SLEEP) print("Going to sleep") machine.deepsleep(300000)