Ah ha. I was using the wrong interrupt script. This is the correct working code for an accelerometer interrupt (P13) of machine.deepsleep(): import machine machine.pin_deepsleep_wakeup(['P13'], machine.WAKEUP_ANY_HIGH, False) machine.deepsleep(10*1000) So for pin interrupts there is a callback() function to create interrupts of active and sleep modes but the pin_deepsleep_wakeup() is needed to interrupt deep sleep (is that what you meant by "wake-on-pin" @jcaron?). There is no interrupt handler for pin_deepsleep_wakeup() because the working memory is cleared after deep sleep (as mentioned by @jcaron below). @jcaron I had tested my interrupt handler without sleep and it did work. In my main.py I had the following script to test that it woke from deep sleep and ran main.py. import pycom import utime pycom.heartbeat(False) #turn off LED pycom.rgbled(0xFF0000) #red LED utime.sleep(2) pycom.heartbeat(False) #turn off LED

@dmayorquin Amazing! Both of those solutions worked for me. Thanks for your help :)

@timh Well in embedded programming for example one of the lpc4000 series with a proper debugger you can "walk" through the code and see at any given point in the code what value any given variable has. That's the real thing i'm missing with python: a decent debugger where i can set breakpoints, evaluate and and manipulate RAM variables and cycle through lines of code. this And i believe that wrapping everything in try and catch can make you a lousy/lazy programmer. For myself i only add try and catch if everything works as it should. Than add them to give the option to continue running with less functionality or save some variables and reboot. As for now i'm liking C much more. But there is also an enormous difference in experience. I've been programming all kinds of embedded microcontrollers in C for years, and probably python is never gonna catch up. I have to get more used to coding in python and i will. I guess i'm not so used anymore to make beginner mistakes ;)

@jmarcelino Yeah, all up to date to the latest firmware. We are working them pretty hard, I guess they are reaching somewhere into the 45+ degrees C

hi @sprasad, So you're interfacing orientation sensor directly with GPY, right? You could control RST pin of GPY, or control Vin(3.5V-5.5V) from your powering scheme.

@sprasad said in GPy with BNO055 - I2C bus error: I2C(0, I2C.MASTER, baudrate=1000, pins=(Pin.exp_board.G15, Pin.exp_board.G16)) > ``` Expansion board G15 and G16 are P8 and P9. P8 is the SD_Data, but You don't use the SD card, the P9 on expansion board is the "led" pin. Try removing the led jumper "enable led signal" on expansion board to disable it.

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.

@meirssv you can save this info to sd card, flash or nvs

@crumble thanks for your tips and enthusiasm. I'll keep you posted as I progress on the project, but time is scarse so don't hold your breath :-) You're not the first to bring to my attention the "good diffusor" issue.

Hi @Xykon , Thanks for reply, that works for the PySense update! The Battery I am using is a 3.7v 2000mAh. Thanks Michael

@bucknall : @chrisi runned into one of your documentation errors: https://docs.pycom.io/pycom_esp32/pycom_esp32/tutorial/includes/pytrack-examples.html#axis-accelerometer you might adapt the example as mentioned above.

@livius os.uname()                                                                                                           (sysname='WiPy', nodename='WiPy', release='1.7.5.b2', version='v1.8.6-694-g25826866 on 2017-06-29', machine='WiPy with E SP32') pytrack firmware: pytrack_0.0.3.dfu yes I git-pulled the lastest library

@asaph I've tried it out and it works fantastically 🎉 Thanks @Daniel!

@Jiemde This is correct! They use the same sleep method as the deep sleep shield to control the devices sleep. I.e. setup_sleep() + go_to_sleep().

@Lokefar I'm happy to help with clean up and testing your code.