FiPy current consumption analysis
-
Hi!
I'm doing a project with LoRaWAN on the FiPy where I'm going to measure the energy consumption of the device when sending and receiving packets over LoRa (it's for a master thesis I'm writing).
I have the FiPy connected to the PyMakr development board and I'm reading the current consumption of the whole node (FiPy + pymakr) connected through USB to a PAC 1932 board. I started out reading the Idle current consumption of over 300 mA. I realized after a while that some other radios on the device might be on and after turning off WLAN, Bluetooth, LTE and Server (don't know if this has an effect, but it was listed under network, so I gave it a go) the Idle current consumtion dropped to somewhere between 60-70 mA, which is in accordance with the FiPY specifications (https://docs.pycom.io/chapter/datasheets/downloads/fipy-specsheet.pdf)
However to be able to monitor the energy consumtion of the device in a fulfilling manner I need to turn off everything that I don't need (basically everything but LoRa and OneWire since I'm using a DS18X20 thermometer for my application) so that I can get as clear a picture over when there is a rise in the current consumption and what is causing it.
There seems to be something else that's running because at some interval there is a spike or peek in current consumption to about 100-110 mA. This interval doesn't seem to be fixed but it sometimes is 10 seconds or 40-50 seconds between the peeks. This happens when I'm not running anything on the device (see picture for details). 
Does anybody have a suggestion to what the cause of these spikes might be (the LoRa radio trying to signal perhaps?) and is there something else that I could try to turn off to get the Idle consumption even further down?
Any help is highly appreciated!
-
Have been looking at power consumption and have similar issues to what is reported here have 200mA in main program then 190 to 150 mA for 30 sec before dropping to deep sleep. In first cycle deep sleep current is 200 micro amps. In subsequent cycles the deep sleep current is 30 mA. Have tried turning everything off without change. Have same issue with LTE but don't have a SIM. Agree that things should not be instantiated by default but as required.
-
@dylan
No problems Dylan let me know how you go - I work for the Metro Fire Brigade In Melbourne - We are about to start evaluating the FiPy board on Telstra so very keen to get feed back on how you went.I am just waiting on our sim pack to arrive from Telstra and the boards.
-
The LTE doco at
https://docs.pycom.io/chapter/tutorials/lte/cat_m1.html states the following:
"IMPORTANT: Once the LTE radio is initialized, it must be de-initialized before going to deepsleep in order to ensure minimum power consumption. This is required due to the LTE radio being powered independently and allowing use cases which require the system to be taken out from deepsleep by an event from the LTE network (data or SMS received for instance).+
When using the expansion board and the FiPy together, the RTS/CTS jumpers MUST be removed as those pins are being used by the LTE radio. Keeping those jumpers in place will lead to erratic operation and higher current consumption specially while in deepsleep."
https://docs.pycom.io/chapter/firmwareapi/pycom/network/lte.html states the following
"lte.deinit()
Disables LTE modem completely. This reduces the power consumption to the minimum. Call this before entering deepsleep."
-
@adrianbro I am using the Pytrack board, I must have made the assumption that the it was talking about the main expansion board, but that does seem possible. As for removing the RTS/CTS jumpers, would that be literally cutting the LTE_RTS and LTE_CTS pins from the FiPy :S.
-
The LTE doco at
https://docs.pycom.io/chapter/tutorials/lte/cat_m1.html states the following:
"IMPORTANT: Once the LTE radio is initialized, it must be de-initialized before going to deepsleep in order to ensure minimum power consumption. This is required due to the LTE radio being powered independently and allowing use cases which require the system to be taken out from deepsleep by an event from the LTE network (data or SMS received for instance).+
When using the expansion board and the FiPy together, the RTS/CTS jumpers MUST be removed as those pins are being used by the LTE radio. Keeping those jumpers in place will lead to erratic operation and higher current consumption specially while in deepsleep."
https://docs.pycom.io/chapter/firmwareapi/pycom/network/lte.html states the following
"lte.deinit()
Disables LTE modem completely. This reduces the power consumption to the minimum. Call this before entering deepsleep."
-
I have had success connecting to LTE which has led to a deepsleep current of around 20mA. However still have not been able to drop to the 20uA.
I am using bits and pieces of the code found in this discussion and I've tried it on different firmware versions as well. Does anyone see anything wrong with this code?
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)
-
@nalexopo Is there an easy way of checking if your SIM supports Cat-M1 or NB-IoT? I am following up with Telstra at the moment however it could be a few days until someone who knows gets back to me.
-
@nalexopo @Dylan Same here. The minimum deep sleep current on average is around 12 mA in my experiments.
-
@dylan
I came to the conclusion that in order to have a constant low current you have to use a working SIM that supports Cat-M or NB-IoT. I just used @MartinN 's code and a working sim. Pycom has to fix this.
-
@nalexopo I am also having problems getting the 20uA deepsleep current draw, would you be able to share any working code you had that achieved 20uA?
So far I have gotten it down to 30mA (also tested it with MartinNs code and got the same).
This is with a SIM card, I found that without a SIM I couldn't lte.deinit() at all.Cheers
-
@thomand1000 I forgot to mention that in the first case the current draw remained at about 200mA for as long as half a minute or less before going down to 20uA. I edit that too on original post
-
@nalexopo Have you looked at what happens right before deep sleep? In my case the device draws about 200 mA of current for 1-2 seconds and then goes into deep sleep. I've discussed it with Pycom here: https://forum.pycom.io/topic/3165/all-radios-on-by-default/2, which believes it might be the LTE modem getting ready for deep sleep (a potential bug), but it would be interesting to know if you experience the same behavior.
-
I currently develop a battery based project on fipy with some sensors and these are my 2 cents on current draw. I presently use Lora but I plan on switching between ALL networks if I can.
-
I tried with machine.deepsleep() without switching off anything, without SIM CARD. Sometimes the device would sleep with a 20uA current draw, but it would draw 200mA or 30mA current for 1-30 seconds after the supposed end of program before really sleeping . Sometimes it wouldn't sleep and the current dissipation would be either 30mA or 200mA steady. It was random as far as I could say
-
I tried with machine.deepsleep() with switching off with @MartinN 's code and I have same behaviour with him but current doesn't always decrease.
-
With SIM card installed and @MartinN 's code machine.deepsleep() works as expected. 20uA current draw always on sleep, LTE offs without delay
-
-
@jmarcelino I see that you are active on the forums and always explaining things in a good way. Maybe you can look into this and explain what is happening? Or what we are doing wrong?
I'm using the FiPy in experiments on my master thesis and really need the deep sleep to be able to monitor the energy consumption on my device in a good way. So it's pretty urgent getting this to work.
Thanks!
-
@thomand1000 You are indeed right, I don't have a SIM card present! And indeed this whole situation is strange, after booting the system has LTE on (based on the high power consumption) even if there is no SIM card available, and when you want to turn the LTE off it does not succeed in a proper way because there is no SIM card present..... It looks like Pycom has some serious work to do here!
@thomand1000 I have not yet entered the area of deepsleep, because I first wanted to understand the normal power consumption....
Overall it is really strange, it looks the system has more or less every power hungry peripheral on by default and in order to preserve power you have to instantiate and deinit any of these peripherals you do not use manually in your application. Pycom can you explain and comment on this? Maybe provide some code examples how to reach the idle current as mentioned in the spec sheets.
-
@martinn I have made som progress debugging your situation. When I removed the nano sim card on my FiPy the LTE.deinit() part of your code threw en error just like in your case. When I put it back in it deinited right away. So I guess that you need to have a sim card in the FiPy to be able to deinit LTE. Strange...
-
@martinn Hi! I have basically used the same code that you have. LTE turns off on my system. I have never experienced any trouble with it and my output from running your code is like your console output (same Device, firmware, python and micropython) except that the Exception never occured.
I'm sorry that I can't help you with why this is happening. I am experiencing a lot of strange things when I have had the system up for a long time. An example is that when I measured the idle (no radios) current it was around 60-70 mA. After a while testing with different scripts running lora this suddenly jumped to about 100 mA (nothing else turned on). I rebooted the FiPy but it didn't work. After rebooting the computer I had connected to it as well the current went down to 60-70 mA again...
I have another thread going on the forums on deepsleep current by the way. If you have any experience with deep sleep on the FiPy any help would be highly appreciated. The way it works now is that when running machine.deepsleep() the current rises from 60-70 mA to 160 mA. The same happens if I change the last line of your code above from machine.idle() to machine.deepsleep(). Very strange!
-
I have been doing some current measurements when the FiPy (and other modules) are actually doing nothing (running machine.idle() in an infinite loop)
My experiences: When using Firmware 1.17.3.b1, a lte.deinit() often (not always!) result in an OSError exception. And even after looping until it succeeds, it takes a considerable amount of time before the current actually decreases to values comparable to those as mentioned in the datasheets
Question: Which firmware do you use and what code do you use to reliably and quickly switch off LTE? Any code suggestions for me, eg other peripherals I am missing?
My code:
print('Device: ' + uos.uname().machine) print('Firmware: ' + uos.uname().release) print('Python: ' + sys.version) print('MicroPython: ' + str(sys.implementation.version[0]) + '.' + str(sys.implementation.version[1]) + '.' + str(sys.implementation.version[2])) print('===============================================================================') print('Switching off Heartbeat') pycom.heartbeat(False) pycom.rgbled(0x000022) print('Switching off WLAN') wlan = network.WLAN() wlan.deinit() 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.EU868, power_mode=LoRa.SLEEP) if (uos.uname().sysname == 'FiPy'): print('Switching off LTE') lte = network.LTE() quit = False while quit == False: try: lte.deinit() except OSError: print(' Exception occured, retrying...') pass else: quit = True print('Switching off Sigfox') # sigfox = Sigfox(mode=Sigfox.SIGFOX, rcz=Sigfox.RCZ1) print('Switching off RGB Led') pycom.rgbled(0x000000) print('===============================================================================') print('Now perform measurements ... ') while True: machine.idle()Console output:
Device: FiPy with ESP32 Firmware: 1.17.3.b1 Python: 3.4.0 MicroPython: 1.8.6 =============================================================================== Switching off Heartbeat Switching off WLAN Switching off Server Switching off Bluetooth Switching off LoRa Switching off LTE Exception occured, retrying... Exception occured, retrying... Switching off Sigfox Switching off RGB Led =============================================================================== Now perform measurements ...
-
@thomand1000 We would need to see your code, as the LoRa radio shouldn't send anything at all unless you ask it to. Contrary to other technologies such as Wi-Fi or cellular, there is no regular activity, a class A LoRa node just sends when asked to, waits for the RX windows, listen a bit, and should then stop (unless you use confirmed packets and the ACK isn't received of course).
If you start a LoRaWAN join it will retransmit until it receives an accept, but the pattern should be quite predictable.