Lopy 4 and Pytrack does not wake up from the sleep.

[pytrackuser1]

I'm having issues with the board wakeup after a random number of sleep. Following is the detailed description.

• Board: Lopy 4 with pytrack
• Firmware: 1.20.1.r2 Pybytes: 1.3.0
• Pytrack firmware: 0.0.8

I'm using fllowing code segment to sleep specified amount of time and wake up continously.

from pytrack import Pytrack
from DS3231 import DS3231

print('Starting main')
pycom.rgbled(0xff00)
#     # Init Objects
py = Pytrack()
print('After init pytrack object')

rtc = DS3231()                          # RTC Object
time = rtc.get_time() # Try to get the time as soon as possible
print("Time", time)
for i in range(0,10000):
    pass
print('after wait')
py.setup_int_pin_wake_up() ## run if you want to interupt off the external OI pin 6
print('Setting up wake up pin')
# go to sleep for sleepTime seconds maximum if no accelerometer interrupt happens
py.setup_sleep(720)
print('After sending sleep')
py.go_to_sleep(False) # disable back-up power to the GPS receiver
print('After turning off GPS power')

The output will look similar to this:

Boot
WMAC: 30AEA4EC7CA8
Firmware: 1.20.1.r2
Pybytes: 1.3.0
WARNING! Your sigfox radio configuration (RC) is currently using the default (1)
You can set your RC with command (ex: RC 3): pybytes.set_config('sigfox', {'RCZ': 3})
See all available zone options for RC at https://support.sigfox.com/docs/radio-configura
Connected using Sigfox. Only upload stream is supported
Pybytes connected successfully (using the built-in pybytes library)
Pybytes configuration read from /flash/pybytes_config.json
Starting main
After init pytrack object
6
1
Time (2020, 1, 27, 16, 23, 56, 0, 0)
Previous board is not available anymore

• Exact steps to reproduce this issue
  1. Upload the code.
  2. Let the board run the code in sleep and wake up cycles.
• What I expected
  • Wake up in every ~12 mins and light the LED and run empty loop continuously and go to sleep again.
• What happened instead
  • These wake up and sleep cycles works as expected in every 12 minutes for around 16 hours correctly but after that, the board stops waking up. Same result with USB charger power adapter to power the device and as well. Tried using laptop power (laptop is always in the wake-up mode.) and in the console, no errors but did not wake up from the sleep. Using the time printed in the console it is able to see it was working fine before but suddenly stopped waking up.

If anyone can help, that would be great. I have already posted this in the firmware git repo as an issue but no one replied for a week.

Thank you!

[catalin]

hi @pytrackuser1 and @jcaron

I've run an similar experiment, on Pysense, for some 12-14 hours and it didn't failed (sleep cycles were 20sec). I've used a 2Ah battery, and recharge it once during the experiment.
I've met such situation, but the battery was weak, 3.6V showing on pysense.read_battery_voltage(), indeed it did not wake up.
You could log into NVS last value of: the battery voltage, number(count) of restart, time from RTC, maybe we notice a pattern. Computer could go into in standby, and minimise USB power source; but you said you've used a power adapter...
One question, after the block, you just cycle power and it works fine, isn't it?
OK, I will try to monitor power usage, maybe I can detect something.

To disable Pybytes:

• we’ve just released v1.20.2.rc3, which supports the method pycom.pybytes_on_boot(False)
• for the previous versions, there are 2 commands:

>>> pybytes.smart_config(False)
>>> pybytes.set_config("pybytes_autostart","false")

[pytrackuser1]

@jcaron thank you very much for your reply.

Status of the LED is off. It just lit up for like half a second and then turned off.

Yes, I noticed that I won't get the last bit of print statements because the device goes to sleep. That's alright for me. I added those just to see what's going on and the added time to see from the console (VS Code console) when it was actually stopped waking up. I had a long program here sending sigfox messages, reading from an accelerometer, writing data to SD card and stuff but after noticing this wakeup issue, I coded this bare minimal code to isolate the issue.

Yes, I have measured the current draw during sleep and waking up cycles. During wake up it draws around 60-140mA current and when it is in sleep it only draws around 1.16mA. That significant amount of low current means actually it goes to sleep mode I guess.

No, I don't need Pybytes and I'm not sure if it is possible to disable that. If you know how to, please let me know. And I had the same issue when I had an old version of firmware which hasn't got Pybytes (At least the log message regarding Pybytes was not there).

I have already disabled WiFi on the device.

I'm using Pytrack firmware version pytrack_0.0.8.dfu which I have downloaded here

In this case, I'm not using battery power at all. I'm using mains USB power adaptor and also tested with a laptop USB port as well. I had the same issue in both of the cases.

[pytrackuser1]

This post is deleted!

[jcaron]

@pytrackuser1 What was the state of the LED? If the LED was on, then either the board didn't go to sleep rather than didn't wake up, or it had issues after waking up. In that situation, changing the LED color before the start of the sleep procedure would help make the difference.

Debugging over USB is difficult, as when the Pytrack goes to sleep (actually as early as the setup_sleepcall), you won't have USB, and it takes a little while for USB to come back up after it boots (and still a little more time for whatever terminal you use to detect it), so you may be missing messages.

The most accurate way of tracking what happens during wake/slep cycles is to monitor current draw over time and to check if the power actually goes down to sleep levels, and if it comes back up.

Do you actually need Pybytes?

If you don't use WiFi or BLE, you may want to set wifi_on_boot to false to reduce the power-on peak current draw.

I suppose you have the latest firmware for the Pytrack? (0.0.8 IIRC).

Many issues related to not waking up end up being due to a brown out, the power source not being able to provide enough current for the peak at startup. Make sure your power source is capable of sustaining that peak.