GPY deepsleep High current



  • @tuftec You are right as this setup cannot be more simple and it show a consumption many more time the one I was planning for according to the doc, affecting greatly my estimated battery life ( wake up 2 time a day, so most of current is sleeping). I'm not sure how to get the attention of someone from Pycom as this is a community forum, but I think we will require this ( I really dont know what else I can test on my side).
    Ill try to understand how it work to contact them or if they read message on this board.

    Meanwhile thanks for the help.



  • @bouchard-claude
    I would expect that the power consumption should be pretty low with your test setup. I think we need some comment from Pycom on this one.
    I expect it is still tied up with the LTE modem power down bug.



  • @bouchard-claude said in GPY deepsleep High current:

    from network import LTE

    Thanks @tuftec , funny enough, I was actually testing this as you wrote me this reply. So I ran this simple code with nothing attached to the GPY ( powered by VIN). I'm not 100% sure of my code, But I think it really make sure I dont have any pull resistor on any pin + making sure the LTE if off. and im still getting the exact same 280 uA while deepsleeping... im still trying to figure out

    import machine
    import time
    from machine import Pin
    from network import LTE
    time.sleep(10) 
    p_in = Pin('P1', mode=Pin.IN, pull=None)
    p_2 = Pin('P2', mode=Pin.IN, pull=None)
    p_3 = Pin('P3', mode=Pin.IN, pull=None)
    p_4 = Pin('P4', mode=Pin.IN, pull=None)
    p_8 = Pin('P8', mode=Pin.IN, pull=None)
    p_9 = Pin('P9', mode=Pin.IN, pull=None)
    p_10 = Pin('P10', mode=Pin.IN, pull=None)
    p_11 = Pin('P11', mode=Pin.IN, pull=None)
    p_12 = Pin('P12', mode=Pin.IN, pull=None)
    p_19 = Pin('P19', mode=Pin.IN, pull=None)
    p_20 = Pin('P20', mode=Pin.IN, pull=None)
    p_21 = Pin('P21', mode=Pin.IN, pull=None)
    p_22 = Pin('P22', mode=Pin.IN, pull=None)
    p_23 = Pin('P23', mode=Pin.IN, pull=None)
    
    lte = LTE()
    lte.init()
    lte.deinit()
    print('sleep')
    machine.deepsleep(30000)
    
    


  • @bouchard-claude The latest firmware actually has the LTE modem enabled on boot so that may still be an issue. You may still need to disable it, but understand from other reading that this is a know issue currently that is still to be fixed.

    You might need to check your logic external to the Gpy device. Try forcing the output pins into a defined state (using the pin hold function) prior to going into deepsleep, to minimise any leakage paths.



  • Small update: I tried with this very simple code to eliminate LTE modem issue:

    import machine
    import time
    time.sleep(20) 
    machine.deepsleep(30000)
    
    

    and i Got the same 280 uA current on deepsleep. So Im not sure if at that point I should look at the board itself ? My understanding is that if I dont init any radio, everything should be off...



  • Thanks, I will try this and see if it help ! For now I Have aroung 280 uA after removing the detach. Wish is way better, but I think I should be able to get lower than that?? I was expecting agout 50-60 is i'm not mistaken?
    alt text

    Also after monitoring the system with the serial interface , I saw that I got a 'LTE modem is in data state, cannot send AT commands' while connecting ( it only happen rarely). This crashed the execution and may explain why my batteries where draining so fast ( maybe the module got stuck in a crashed state, in full power mode). I removed the AT! debug command and also added a watchdog ( using WDT). That explain why battery goit drained very fast, but not explain the still high current..
    Many thanks for the help and ill keep you posted



  • Yes! If you're not using PSM https://development.pycom.io/tutorials/lte/power/#power-saving-mode you most likely don't want to use detach=False



  • My understanding is that lte.deinit with detach=False leaves the modem radio switched on during deepsleep. Maybe try a regular lte.deinit() instead?


Log in to reply
 

Pycom on Twitter