All radios on by default
-
Hi!
Why is all radios on by default on the FiPy? Seems like a bad design choice for an IoT device that most likely will run on batteries. The way the FiPy works now is that all radios are turned on after boot and you will have to manually turn every single one off to get the energy consumption down. You also have to redo the process of turning them off after every deep sleep. Why have you designed it this way?
-
@jmarcelino I've tested this now (removed lte = LTE() and lte.deinit() ) and the peak is still there. The device goes into deep sleep, but like before the current rises quickly to about 200 mA for a couple of seconds before it goes into deep sleep. I also find it strange that it doesn't happen the first time the device goes into deep sleep, but all consecutive runs. The first time now, since I don't deinit() LTE the current is at about 200 mA and drops down to deep sleep. Then when waking up it is around 60-70 mA when measuring and then peaks to 200 right before deep sleep.
-
@thomand1000
If you don't actively use the LTE it's actually better not to deinit() it, don't call LTE module even. The modem should automatically go into deepsleep mode.
-
@jmarcelino Yes. I'm deinit WLAN, Server, Bluetooth and LTE. I'm also doing pycom.wifi_on_boot(False). It seems to work since the consumption drops a lot. And everything seems fine until I'm going into deep sleep the second time. I'm never doing any of these deinit() calls again. Should I?
-
Hi @thomand1000
Are you calling LTE.deinit() by any chance? Are you using LTE at all?
-
@jmarcelino Cool. My work on the FiPy is part of a master thesis where I'm doing test on energy consumption for different setups. I'm basically testing different algorithms or models that decide how often a device needs to send data to the server. A good model would send data less often than another less good model, because sending is more expensive. I'm doing tests where I accumulate power consumed by the device over a given time. For a good model, the result should be that it consumes less power and uses more time in deep sleep. However, with the potential bug with the 200 mA peaks, a good model that goes into deep sleep more times than a bad model would in the long run possibly consume more power. So my tests would be corrupted.
I need to have a realistic expectation as to if my tests would be possible to perform before the deadline of my thesis. So, if you find the bug and a potential fix for it, how fast can a new firmware be deployed that fixes it?
-
Hi @thomand1000
I believe those peaks are the FiPy actually preparing the LTE modem for deepsleep, but if so it definitely could adopt a smarter strategy to go about it.
We'll investigate, thank you for your obvservations.
-
@jmarcelino I now see a substantial drop in current after powering the device through the VIN. Thanks! Do you have any ideas as to what the peaks of about 200 mA could be btw? I still see them after powering through VIN. Strangly this doesn't happen the first time the device goes into deepsleep, but all consecutive runs. Before I go into deep sleep I store the lora state with lora.nvram_save(). Is this an expensive operation? I guess it's overwriting the state in ram, but this shouldn't take a couple of seconds of around 200 mA current drain? Any help is highly appreciated!
-
@robert-hh No SD-card connected, but thanks for the tip!
-
@jmarcelino Ah, thanks! I've never tried powering trough the Vin pin before, but I'll give it a try.
-
@thomand1000 Do you have an SD card plugged into the interface board? That adds another ~5 mA.
-
@thomand1000
Connecting over USB you'll see an added, constant, power consumption from the USB-Serial chip (Expansion 2) or PIC micro (Expansion 3) as well as the USB LED.
-
@jmarcelino through USB. It’s connected to a PyMakr dev board
-
@thomand1000
How are you powering the FiPy and measuring the current?
-
@jmarcelino Ok. The following is what I'm getting in current consumption. Deep sleep is around 15 mA (after I found the info that the RTS and CTS pins should be taken off. This info should also be under deepsleep docs). 15 mA is still a bit high right?
In the image you can see that the device wakes from deep sleep, sends a packet over LoRa, checks if there is anything incoming from the server and then goes into deep sleep again. I have checked my code and put in pycom.rgbled and timers before the machine.deepsleep(20000) I have in my code and the over 200 mA peak in the picture happens every time for about 2 seconds before the device goes into deepsleep.
Any ideas to what it might be? I use nvs_set and nvs_get to store some variables during deepsleep, but I'm pretty sure that this isn't an I/O operation causing this. This happens at a different time in my code anyway, so I don't think that is the cause. I removed the nvs_get/nvs_set and the peak is still there...
-
You can disable the WiFi (and Bluetooth since it's the same) radios by setting
pycom.wifi_on_boot(False)This is stored internally and WiFI will not turn on again until you either initialise it manually or set pycom.wifi_on_boot(True)
For LoRa/Sigfox this isn't an issue as the radio is only active if you enable it.
The LTE modem should retain the last powered status for deepsleep cycles (using machine.deepsleep())
