@misterlisty that’s about as vague as it gets... I recommend you start by reading the accelerometer’s datasheet to learn of its capabilities. An accelerometer detects just that: acceleration, and you can sample the acceleration values at regular intervals to try to detect all sorts of things. I believe you can even “stream” the values samples by the accelerometer. But high frequency vibrations for instance may be an issue as they may exceed the capabilities of the accelerometer. High sampling rates may also be an issue if you have lots of computations to perform. It’s really difficult to help you much further without any indication of what exactly you are trying to measure / detect, and what the threshold are.

@jcaron any news?

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.

Any luck with new wipy users ?

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

@crumble Pictures of the larp kit please :P Ill dig mine out in return ^_^ @arthurlutz Thats super cool. good work.

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.