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.0Still 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 Pytrackprint( "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...
