@alexpul if you want low power it’s going to be one of the last two. On a WiPy 3 the recommended option is machine.deepsleep, though I haven’t checked whether it can be used with wake-on-accelerometer. You probably won’t be able to capture the acceleration at the actual time it is over 3g, though, it takes a little while for the WiPy to wake up...

I have summarized my current understanding of the various was to enter sleep mode in this post. The general idea though is that sleep allows the board to still run (but with reduced power) and it does not reset when you exit sleep. Deep sleep resets the board (will not execute any code after the deep sleep command and will reboot and run boot.py and main.py)

@fstaine WAKE_REASON_INT_PIN: can be generated from PIC_RC1(pin6 on External IO Header) https://docs.pycom.io/chapter/datasheets/boards/pytrack.html <later edit:> Please take a look here function pytrack.setup_int_pin_wake_up([rising_edge = True]).

Hi @jcaron, yesterday I posted some findings about this issue. Today I've discovered that if I comment the line: self.set_register(CTRL3_REG, 1, 5, 1) in LIS2HH12.py, then my multimeter shows the accelerometer works as its supposed in terms of current consumption: ~130 µA for 5 seconds (inactivity duration) and then ~60 µA. If I shake a little bit the board then the current rises up to ~130 µA (activity detection) and after 5 seconds lowers to ~60 µA again. Off course, the SiPy doesn't wake up because accelerometer's inactivity interrupt (INT1_INACT bit in CTRL3 register) is not enabled (the line I commented), but this reinforces my theory that there is a problem regarding to the way the PIC handles the interruption. I.e., an issue in Pysense/Pytrack firmware or in pycoproc.py library.

@rskoniec Thanks, it helped debugging. If I unplug the power completely it shows the POWER_ON_WAKE, but if I do a manual reset (button pressed) it says TIMER_WAKE. I reckon it's a bit confusing. I couldn't see the values after connecting the USB and reconnecting to the console, so I assumed a manual reset would be treated as a POWER_ON_WAKE.

@jellium This is not possible yet, please see the existing topic: https://forum.pycom.io/topic/1350/strategy-for-lorawan-with-deepsleep-2

@jmarcelino Is there any example code that incorporates deepsleep and LoraWAN with these new functionalities to test it? thanks