All radios on by default

[jmarcelino]

@thomand1000
How are you powering the FiPy and measuring the current?

[thomand1000]

@jmarcelino through USB. It’s connected to a PyMakr dev board

[jmarcelino]

@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.

[robert-hh]

@thomand1000 Do you have an SD card plugged into the interface board? That adds another ~5 mA.

[thomand1000]

@jmarcelino Ah, thanks! I've never tried powering trough the Vin pin before, but I'll give it a try.

[thomand1000]

@robert-hh No SD-card connected, but thanks for the tip!

[thomand1000]

@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!

[jmarcelino]

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.

[thomand1000]

@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?

[jmarcelino]

Hi @thomand1000

Are you calling LTE.deinit() by any chance? Are you using LTE at all?

[thomand1000]

@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?

[jmarcelino]

@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.

[thomand1000]

@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.