Does deepsleep work at all



  • I am working with the SiPy board with extension board. A very simple setup - boot without any wifi commands (seems to boot wifi anyway?)
    read sensor values using uart commands
    use s.send(xxx) to send via sigfox
    deep.sleep (600000) = 10 min.
    It is powered through USB.
    Has any one any succes with deepsleep? I know about the power issues - but I am currently more concerned about the stability of the function. For me it wakes up and runs boot.py - and not as stated in the "getting started" - in the main script. This runs around 5-8 times and then stops. It might be in the main.py - but surely a lot of wifi stuff is going on every time it wakes up.

    Anyone had succes with deepsleep? Just a simple setup.

    Best regards, Adam



  • @johncaipa Hi, Im getting this same error - did you work out why this occurs?



  • @robert-hh Of course is bad ! Is all about what you pay and what you get !

    For wireless sensor the deepsleep curent is critical !



  • @robin Do you sleep and then restart the hole aplication and then you go to sleep again?



  • @robin Even if 520µA is large compared to 25µA, it's not that bad. A typical 18650 LiPo cell can serve that for 8 months (3000 mAh/0.52mA = 5769h or ~240 days). Once you're sure that besides the battery your set-up will run for that period, the battery becomes an issue. And the more frequent your device communicates, the less important is the standby current.



  • @daniel i am still waiting on a solution to the 520 uA instead of <25uA problem for

    • the deep sleep shield
    • on a LoPy
    • attached to a LiPo battery

    We are about to put 10 LoPy's into the wild to fend for themselves and report back with tales of great adventures.....but the current is still killing the battery.
    A month ago you mentioned you guys were working on it. When can we expect a solution?

    @colin-guyon said in Does deepsleep work at all:

    @daniel Hello, do you know if a solution is going to be raised about the deep sleep high current (520 uA at 5v instead of few uA that were announced) ? Thanks



  • @colin-guyon yes we will sort it out, we just need need a few more days to crack it as other things have delayed us.



  • @daniel Hello, do you know if a solution is going to be raised about the deep sleep high current (520 uA at 5v instead of few uA that were announced) ? Thanks



  • @daniel @jmarcelino
    Ok back to testing, I got the point (It actually took a long time to get deep into my brain!) Once the board in deepsleep mode, there is little chance I could get a console connection to it...



  • @jmarcelino @daniel
    Solved.

    For the sake of it, I've tried with another USB cable among other stuff. The only thing I did not do is reboot the internet...

    Sipy: upgraded firmware to the brand new 1.8.0b1
    Pytrack: re-upgraded firmware to 0.0.4
    Pymakr in Atom: checked latest version 1.1.0

    Still no heartbeat.
    Sometimes I got a connection to the board (after multiple connect clicks).
    Main.py was then running with weirdo character when printing pytrack firmware version (instead of 4), followed by deepsleep command.
    Console connection was immediately lost right after.

    After a safe boot with latest firmware (1-3 sec), I managed to get a console prompt and reset the code part. Everything is back to normal, will get back to testing the deepsleep.



  • @daniel Got this during Pytrack firmware upgrade:
    Match vendor ID from file: 04d8
    Match product ID from file: f014
    Deducing device DFU version from functional descriptor length
    Opening DFU capable USB device...
    ID 04d8:f014
    Run-time device DFU version 0100
    Claiming USB DFU Runtime Interface...
    Determining device status: state = dfuIDLE, status = 0
    dfu-util: WARNING: Runtime device already in DFU state ?!?
    Claiming USB DFU Interface...
    Setting Alternate Setting #0 ...
    Determining device status: state = dfuIDLE, status = 0
    dfuIDLE, continuing
    DFU mode device DFU version 0100
    Device returned transfer size 64
    Copying data from PC to DFU device
    Download [=========================] 100% 16384 bytes
    Download done.
    state(2) = dfuIDLE, status(0) = No error condition is present
    Done!



  • @Arnaud, I think the firmware upgrade failed. Just tried it again using the DFU procedure.

    Cheers,
    Daniel



  • @Arnaud
    Can you try another USB cable?



  • @jcaron
    I have updated the pytrack firmware to 0.0.4 with DFU-util (Mac OSX).

    From there:
    The hearbeat (blue led) is not active anymore.
    I have a lot of troubles gettting a console connection to the board.
    Sometimes, the board executes main.py, prints a few lines but hangs on while printing firmware version and connection is lost.



  • @jcaron read_fw_version returns 2.
    Since I haven't done any pytrack firmware upgrades since June, I'll assume I have to.

    This might be a hint for improving docs:
    Required Pytrack Firmware: x.y.z



  • Just to make sure, you have the latest firmware (0.0.4 I believe) on the Pytrack? You can check with pytrack.read_fw_version().



  • @daniel I've tried the latest pytrack lib for deepsleep with very simple main.py:
    from pytrack import Pytrack

    print( "Waking up")

    Some job

    print( "Going to sleep")

    pytrack = Pytrack()
    pytrack.setup_sleep( 10 )
    pytrack.go_to_sleep()

    Waking up with a buton press works.
    Board never wakes up on timer.



  • Nice to hear that! Please help us with a bit more explicit documentation. You might be aware of this now based on the comments, you're building up hours of frustration which is not was intended at first I'm sure with the beautiful specs of your products.

    BTW, I think deepsleep example lacks an import deepsleep for constants.



  • @Arnaud with pytrack or pysense simply use their own libraries which also provide the deepsleep functionality:

    https://github.com/pycom/pycom-libraries/tree/master/pytrack



  • @tmz said in Does deepsleep work at all:

    https://github.com/pycom/pycom-libraries/blob/master/deepsleep/deepsleep.py

    Just tried the deepsleep example on Sipy 1.0 - Pytrack 1.0 with latest deepsleep.py and after firmware upgrade to 1.7.9b3 and got the same error than John.

    I understood that Pytrack serves as deepsleep shield.
    All this deepsleep troubles merged with lack of documentation is really frustrating...


Log in to reply
 

Pycom on Twitter