Expansion board 3.0 power consumption
-
Hi there,
I just bought some lopy4 units and was testing the deep-sleep mode. Current consumption is about 20 uA when the lopy4 is not plugged into the expansion board, which is OK. But, as soon as I try to use the expansion board, current goes to 4mA in deep-sleep mode.
No SD card inserted. All jumpers removed. Is there a way to minimize that current while using the expansion board?What about the pysense board? the datasheets states it only consumes 1 uA in deep sleep mode. Should I just use it for my needs and forget about the expansion board?
Thanks,
Javi
-
@einarj said in Expansion board 3.0 power consumption:
@crumble Your initial answer was using the Pycoproc together with the expansion board 3?
Yes. You came back with i2c problems.
The Pycoproc is used by pysense and pytrack as well. All 3 boards use the PIC for handling firmware update, deepsleep and so on.
But there is a chance to run into this i2c problem - depending on firmware version and your hard-/software setup.
-
@robert-hh Interesting results. I have also managed to get the FiPy and GPy down to uA current draw when the LTE modem is left alone. But having LTE was kind of the reason for using those boards :)
Until Pycom and Sequans have solved all the issues, I'm using a SARA N210 for my NB-IoT tests, together with a LoPy and a Pysense.You can see the power results here:
https://forum.pycom.io/topic/4099/new-firmware-release-candidate-v1-20-0-rc0/50
-
@crumble Your initial answer was using the Pycoproc together with the expansion board 3?
-
@einarj said in Expansion board 3.0 power consumption:
@crumble I have no trouble with either the pysense or pytrack using I2C. Are you using the Pycoproc class as is?
I use only a pytrack and Pycoproc as deployed by pycom plus my own GPS stuff running in a thread.
Depending on the firmware version I was able to find slots in which the init of the pytrack failed always, sometimes or nether. The longer I waited the less i2c errors pop up. I assume that one problem is related to the GPS chip, which will be ready depending on the received signals and stored almanac data.
Additionally I got garbage from the GPS when reading too often but lost chars when reading too seldom.
Sometimes I had this trouble with writes to i2c as well for the deepsleep method of the pytrack.
Checked this with 2 LoPys and a WiPy3, Maybe my particulare pytrack is broken. But I am not the only one with the i2c error related with deepsleep..
I cannot remember these problems on the early firmware versions using only one core. So I bet on a core sync problem. But I may be totaly wrong. At that time I had low i2c load and high chance for out of memory exceptions during or soon after boot. So I may had not enough test runs. But I still bet on a core sync issue. Even if I was not right blaming signal quality, day time, temperature and humidity or drinking a lot of victory coffees ;)
-
@einarj @danielm and me made similar tests a few weeks ago. (https://forum.pycom.io/topic/4106/g01-power-consumption/10) @danielm had seen 7µA on a G01, best case, but very often also 29 mA. I tested with a FiPy, SIM inserted.
After a lte init, attach, connect, disconnect, dettach, deinit, machine.deepsleep, I have seen aconsumption of 290µA 5 seconds after the deepsleep command, and then 40µA after about a minute past the deepsleep command. All that with SIM, but without an expansion board.
@da
-
Just did an experiment with a GPy and the Expansion Board 3.0
Code disables WiFi, BT and does a LTE init and deinit() (simcard present)First run: 180mA - also in deep sleep - reset button does not help
Second run: disconnect and reconnect power - same behavior
Third run: remove the GPy from the expansion board and put it back - 120mA when running - 150uA in deep sleep
Pressed reset on the GPy - stalled at 40mA and stayed there. Turning off and on power didn't help. Removing and putting the GPy back into the expansion board did.Doesn't seem very stable? Running GPy with 1.20.0.rc4 and the expansion board 3.0 with version 0.0.9
-
@crumble I have no trouble with either the pysense or pytrack using I2C. Are you using the Pycoproc class as is?
-
- Add some wait of 2-5 seconds
- try firmware 1.20 rc4
- serialize your i2c calls with a lock.
Many people have problems with i2c. There seems to be no best practice. In my certain setup, I have to wait 5 seconds before i2c usage. Solutions depends on firmware version, your i2c hardware and your i2c calls. So you have to find your own way of sleep, lock and excpetion combinations.
There is only one best practice. Don't trust your first test. Test your stuff over night in a loop with short sleep time.
-
@jas_xcs Without schematics of the board and knowing how you power the board it's hard which components of the expansion board may consume current.
-
@crumble trying the Pycoproc class for the expansion board 3.0 just gives me an I2C bus error exception. Do you have an example?
-
Expansion board 3.0 uses a PIC microcontroller to shorten the pins for the LoPy firmware update. On older expension boards you had to do this manually.
This controller will still run when you send the LoPy into deepsleep. Use the Pycoproc lib to send the PIC into sleep mode. as well
