G01 power consumption

[danielm]

Today I assembled custom board for power consumption tests of G01. Assembled components are only:

• G01
• 10k pull-up for RST
• u.FL connector for LTE antenna + connected antenna
• SIM slot including SIM card

All tests were performed with Pycom Firmware 1.20.0.rc0. G01 is powered directly from Otii Arc (no voltage regulator).

Sequans firmware NB1-33080 (factory default)

import machine
machine.deepsleep()

Deep-sleep current: 7uA

import machine
import network
lte = network.LTE()
machine.deepsleep()

Deep-sleep current: 41mA

import machine
import network
lte = network.LTE()
lte.deinit()
machine.deepsleep()

Deep-sleep current: 41mA

Sequans firmware NB1-37781

import machine
machine.deepsleep()

Deep-sleep current: 7uA

import machine
import network
lte = network.LTE()
machine.deepsleep()

Deep-sleep current: 27mA

import machine
import network
lte = network.LTE()
lte.deinit()
machine.deepsleep()

Deep-sleep current: 27mA

Sequans firmware NB1-38729

import machine
machine.deepsleep()

Deep-sleep current: 7uA

import machine
import network
lte = network.LTE()
machine.deepsleep()

Deep-sleep current: 27mA

import machine
import network
lte = network.LTE()
lte.deinit()
machine.deepsleep()

Deep-sleep current: 27mA

Sequans firmware NB1-40343

import machine
machine.deepsleep()

Deep-sleep current: 7uA

import machine
import network
lte = network.LTE()
machine.deepsleep()

Deep-sleep current: 29mA

import machine
import network
lte = network.LTE()
lte.deinit()
machine.deepsleep()

Deep-sleep current: 29mA

It seems that lte.deinit() is not correctly implemented in v1.20.0.rc0.

According to power consumption it seems that LTE attach process is started after first lte.isattached()!

[danielm]

Pycom firmware v1.18.1.r1 and Sequans firmware NB1-40343

import machine
import network
lte=network.LTE()
lte.deinit()
machine.deepsleep()

Deep-sleep current: 29mA

import machine
import network
lte=network.LTE()
lte.attach()
lte.deinit()
machine.deepsleep()

Deep-sleep current: 7uA
Does not deinit LTE correctly if lte.attach() was not called before!

Pycom firmware v1.20.0.rc0 and Sequans firmware NB1-40343

import machine
import network
lte=network.LTE()
lte.deinit()
machine.deepsleep()

Deep-sleep current: 29mA

import machine
import network
lte=network.LTE()
lte.attach()
lte.deinit()
machine.deepsleep()

Deep-sleep current: 29mA
Does not deinit LTE correctly in any case!

[Colateral]

@danielm After deinit() Did you tried also the scenario to reset machine then go to deep sleep?

[danielm]

@colateral
I did not but I have an information that Pycom is already working on a fix. So let's wait for it and then I will repeat the tests with the same setup.

[robert-hh]

@danielm Tried the same with my FiPy over USB.
a) first attached and connected,
and then ran the sequence:

>>> lte.disconnect()
>>> lte.dettach()
>>> lte.deinit()
>>> deepsleep(60*1000)

The current went down to 11mA, which is just the power consumption of the USB/UART bridge.
I used a simple Chinese current tester for that purpose, resolution 1 mA, so I cannot tell whther the FiPy current consuption went down into the µA range.
And yes: SQNS firmware NB1-40343, FiPy firmware v1.20.0.rc0

[iwahdan]

@danielm , do you have the pycom.lte_modem_en_on_boot flag set or not?

[danielm]

@iwahdan
I did not change the default settings. Will check tomorrow, the board is in my office.

[iwahdan]

@danielm Ok, the issue that we have detected is that since Low power mode is not currently enabled by default in NB-IoT sequans firmware, if lte_modem_en_on_boot is not set , doing just machine.deepsleep without initialising LTE

import machine
machine.deepsleep()

will not put the modem in Low power mode as we enable Low power mode in LTE initialization.

However it is strange that you get these DS currents when doing LTE initialization before going to Deepsleep.

I've tried your code with GPy and FiPy and I can always get Deepsleep current in order of uAmps in case of having LTE initialization before DS
The DS current consumption is high only when having lte_modem_en_on_boot flag not set and going to Deepsleep without LTE init as I described above, which I will push a fix for it tomorrow.

I will try to test also on G01 tomorrow, but I don't think it would be different.

[danielm]

@iwahdan
I checked state of lte_modem_en_on_boot and it returned True. I am sure that I did not set it to True. The module was unused, removed from the reel before soldering. Firmware upgrade sequence until now was factory version->1.20.0.rc0->1.18.1.r1->1.20.0.rc0. This is probably why I measured low DS current values in case I did not initialize LTE before going to DS.

import machine
import network
lte=network.LTE()
lte.deinit()
machine.deepsleep()

I again verified that this code results in DS current of 29 mA.

Then I set lte_modem_en_on_boot to False and disconnected from power for several seconds.

import machine
machine.deepsleep()

This code resulted in DS current of 76mA (checked twice) so there is some difference.

import machine
import network
lte=network.LTE()
lte.deinit()
machine.deepsleep()

This code resulted in DS current of 29mA - 2 of 3 times, 1 hang on lte.init()

import machine
import network
lte=network.LTE()
lte.attach()
lte.deinit()
machine.deepsleep()

This code resulted in DS current of 29mA

import machine
import network
lte=network.LTE()
lte.attach()
lte.dettach()
lte.deinit()
machine.deepsleep()

This code resulted in DS current of 29mA

[danielm]

G01 power consumption test with v1.20.0.rc1.
Triggering deep sleep without LTE init results in 7uA deep sleep current albeit it takes some time.

Running following sequence from REPL results in deep sleep current of 29mA - tested twice.
Based on power consumption it seems that attach process starts after first lte.isattached() command!

Pycom MicroPython 1.20.0.rc1 [v1.9.4-bc4d7d0] on 2018-12-12; GPy with ESP32
Type "help()" for more information.
>>> import machine
>>> import network
>>> lte=network.LTE()
>>> lte.attach(band=20,apn="nbiot.telekom.sk")
>>> lte.isattached()
False
>>> lte.isattached()
False
>>> lte.isattached()
False
>>> lte.isattached()
False
>>> lte.isattached()
False
>>> lte.isattached()
False
>>> lte.isattached()
False
>>> lte.isattached()
False
>>> lte.isattached()
True
>>> lte.connect()
>>> lte.isconnected()
True
>>> lte.disconnect()
>>> lte.dettach()
>>> lte.deinit()
>>> machine.deepsleep()

[robert-hh]

@danielm Using your command sequence with a FiPy, firmware v1.20.0.rc1, the current drops after a few seconds to 290µA, and then to 20µA after about a minute.
With lte.send_at_command('AT!="CBE::powerOff"') between lte.dettach() and lte.deinit() the current drops to 20 µA after a while too, but faster than a minute.
Without LTE init, the current drops to 20µA too. The difference to your test may be caused by the LoRa chip on the FiPy.
For the test, the FiPy was just connected to GND, Vin at 3.8V and an antenna, every other pin was left open.

[danielm]

@robert-hh
Deep sleep current level around 20uA is expected if you take into account quiescent current of LM3281 voltage regulator. In my test I was powering G01 directly without any regulator. You managed to achieve lowest possible current value. Do you have possibility to test with G01 instead of FiPy?

[robert-hh]

@danielm No. I just have development modules.

[andreas]

Dear Robert,

@robert-hh said in G01 power consumption:

Without LTE init, the current drops to 20µA too.

Are you saying that the LTE shutdown magic by invoking lte.deinit() referenced many times in the forum will not be required at all? Our scenario is that we are currently not using the LTE modem of the FiPy and want to get power consumption as low as possible.

We are humbly asking for your experience here, especially with the latest firmware releases.

Also, I just stumbled over lte.send_at_cmd('AT!="powerOff"'), which also does not sound that bad ;]. Maybe this will shut down the modem in the quickest way possible without going through all procedures of the regular lte.deinit().

Thanks already for taking the time to answer our question on this evergreen topic.

With kind regards,
Andreas.