Does deepsleep work at all

[daniel]

@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

[Arnaud]

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]

@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.

[jcaron]

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().

[Arnaud]

@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

[Arnaud]

@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.

[jmarcelino]

@Arnaud
Can you try another USB cable?

[daniel]

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

Cheers,
Daniel

[Arnaud]

@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]

@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.

[Arnaud]

@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...

[colin.guyon]

@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]

@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.

[Robin]

@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

[robert-hh]

@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.

[iotmaker]

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

[chumelnicu]

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

For wireless sensor the deepsleep curent is critical !

[bradnz]

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