Wake up on pick-up



  • Is there any way to program StickC to wake up when it moved eg. picked up? Maybe some behavior from the IMU waking up deep sleep? I'm open for anything.



  • @jhfoo I'm hoping to do exactly this. I'm also hoping to get a bite on this thread re: the new MPU6886 IMU: https://forum.m5stack.com/topic/1400/unable-to-wake-m5stickc-using-sh200q-s-activity-interrupt



  • @davesee I heard about setting a flag on movement detected, written at the C level. Hoping to avoid that level of coding. Will forward your link to my (volunteer) team who do C coding if they can confirm your design.



  • @jhfoo When you say "wake up", do you mean "wake up" the processor from a low-power state? This is my interest so that I can increase battery life.

    I see two ways to do this:

    1. If GPIO35 is connected properly from the MPU6886, then it's a matter of configuring the MPU6886 properly in an arduino sketch or micropython code.
    2. If GPIO35 is NOT connected properly from the MPU6886, then there might a much more difficult solution for arduino or micropython. The ESP32 has a special capability known as the "ULP" core where "ULP" means "Ultra Low Power". This is an advanced topic and not simple, but there's enough documentation and examples online that it should be possible.

    It might be a while, but when I get my M5Stick-C, I plan to try approach 1, and potentially approach 2.

    Boring details below re: approach 2:

    Approach 2 involves writing assembly code for the ULP core. It looks like Arduino and MicroPython both have the ability to run code on the ULP core AND do a "deep sleep". The ULP core can read registers over I2C. So approach 2. requires the following steps:

    1. Initialize I2C pins like normal, but ALSO for ULP registers, so it knows the pins to use for reading I2C - it's effectively a separate CPU core that can share some memory with the main cores.
    2. Initialize I2C peripheral address (i.e. I2C address of MPU6886) by setting registers for the ULP
    3. Read accelerometer registers for X, Y, and Z and calculate energy or change of energy in ULP assembly code.
    4. If that energy or change of energy is past a threshold, the ULP will call the 'WAKE' command to wake up the main ESP32 processor.

    That's a lot to get working well. Let's hope approach #1 can work! :-)



  • @jhfoo I got my M5Stick-C and I can confirm that option #1 does work with an Arduino sketch. It should also work with Micropython but I haven't tested that yet. I'm working on tweaking the settings to get good performance which just means:

    1. Minimize false alarms - i.e. the 'wake-on-motion' doesn't trigger when there's no real movement
    2. Maximize true alarms - i.e. the 'wake-on-motion' does trigger when there's real movement

    I'll post an arduino sketch somewhere when it works. If I can get it to work well, I think it would be a nice addition to the M5StickC arduino library. This would simplify using it for most people. Getting this to work with Micropython should be straightforward once the Arduino version is working well. More to come!



  • @jhfoo I have something working pretty well. I put an Arduino .ino file here:
    https://gist.github.com/standarddeviant/ea0b7f12a32bf5de96992a8ef350351d

    Please be aware, this doesn't (yet) wake up the main processor - it's just a proof of concept to validate that approach #1 will work - and it does!

    What that sketch does is

    • Initializes the MPU6886 similar to other arduino examples
    • Attaches a simple interrupt when pin 35 is RISING using the attachInterrupt Arduino function.
      • this interrupt currently just increments a variable of how many times it's been called
    • Sets registers on the MPU6886 to enable "wake-on-motion". I had to dig through the datasheet for some of these details and one detail in particular was just plain wrong, but that's how it goes sometimes. :-)

    On the display, there are two numbers - one is just a seconds counter and the other is how many times motion has been detected via GPIO pin 35 from the MPU6886. There's a simple rectangle on the LCD display. When motion is detected, that rectangle stays red for two seconds. After those two seconds, the rectangle goes back to blue.

    I'm going to reach out to the maintainers of the M5StickC library to see if this functionality can be included directly in the library - it should be pretty straightforward to include this capability and would simplify using this ability for others. I'll post a video soon showing this sketch in action.

    The sleep/wake functionality is the next step - this Arduino sketch is just a proof-of-concept for the simpler approach #1. Since it's just writing registers over I2C and setting up an external interrupt, this same approach should work with Micropython.

    Cheers,
    Dave



  • Here's a video of that Arduino sketch in action. https://www.youtube.com/watch?v=v5GpsvjFsEw

    Cheers!



  • Just an update: here's an example of waking the unit from deep sleep with the MPU6886:
    https://gist.github.com/standarddeviant/85c31cf34eb51e10aa3bb02dcd0bcbd1

    I'm working on adding this capability to the arduino library so it's simpler to include this functionality in existing sketches.

    Cheers!



  • Hey davesee,
    do you think that your code could be easily changed so your example could work on a M5Stack Grey?

    I want the M5Stack Grey to be in deep sleep and when it's moved (movement should be detected by the IMU) it should wake up.

    greetings



  • Hi @tristar !

    TL; DR - maybe. It depends if the interrupt line is wired between MPU6886 and ESP32.

    There are two questions to answer to know if this method will work with the M5-Grey:

    1. Does it have the MPU6886?
      A: Yes!
    2. Is the interrupt line coming out of the MPU6886 wired in to one of the ESP32 pins that can be used to wake from deep sleep?
      A: Unsure. This isn't clearly outlined in the schematic here: https://docs.m5stack.com/#/en/core/gray

    I wrote some library code to enable this on the M5StickC which is now included in the latest Arduino library here:
    https://github.com/m5stack/M5StickC/blob/master/src/utility/MPU6886.cpp#L101

    I'm happy to suggest or review code so you can test this. Are you using the actual Arduino IDE or something different? It should be straightforward to test with a development version of the library either way.

    Cheers,
    Dave



  • Hi @davesee @Tristar

    In my M5Stack Grey the two ICs (MPU6886 and BMM150) are on a small daughter board which was soldered to the underside of the Groove connector (GND, 5V, SDA, SCK). An additional pin provides 3.3V for the two ICs. But I am afraid the interrupt line coming out of the MPU6886 is not connected at all.

    Please note: My M5Stack Grey board reads 2018.3, so maybe the daughter board was merged with the main board in later revisions?

    Felix

    Desoldered daughter board:

    0_1596493891171_M5Stack_MPU6886_BMM150_board.png



  • hey @davesee

    I have the latest version of the M5Stack gray, but the board also reads 2018.3. I am going to try out your code that you used for M5StickC on my M5Stack Gray with PlatformIO.

    I will report back how it went. All I want is a wake up on movement :). The same thing you got running on your M5StickC.



  • @Tristar

    Just curious - how did your try out go? Have you been able to get @davesee code running on your M5Stack Grey?

    Thanks
    Felix



  • Not yet, but I will invest tomorrow the whole day and try to get his example working on the GREY.
    I have the problem that the GREY just restarts on its own every few seconds. Looks like the GPIO35 is always triggering the wake up call from deep sleep.



  • Hi @Tristar

    How's it going? My two M5Stack Gray and Fire did exactly the same, they would restart on their own. The reason is, as we already expected, that the interrupt output from the MPU6886 is not connected to the GPIO35 (at least not in my two M5Stacks).

    I've fixed that by soldering a wire from MPU6886 pin12 (INT) to GPIO35 and now my M5Stacks properly go to sleep and only wakes up on motion again.

    0_1597849398440_M5StackFire_MPU6886_INT.png

    Cheers
    Felix



  • Hi @davesee

    Thank you very much for your WOM code which I am using on my M5Stack Fire.

    Just curious about the following code lines for WOM step 2:

    • The read regdata are not actually used. Maybe by mistake?
    • Comment says 32 samples, but actually only 16 samples are selected. Typo?
    /*
    Step 2: Set Accelerometer LPF bandwidth to 218.1 Hz
            • In ACCEL_CONFIG2 register (0x1D) set ACCEL_FCHOICE_B = 0 and A_DLPF_CFG[2:0] = 1 (b001)
    */
    I2C_Read_NBytes(MPU6886_ADDRESS, MPU6886_ACCEL_CONFIG2, 1, &regdata);
    regdata = 0b00100001; // average 32 samples, use 218 Hz DLPF
    I2C_Write_NBytes(MPU6886_ADDRESS, MPU6886_ACCEL_CONFIG2, 1, &regdata);
    

    Thanks
    Felix



  • @felmue
    yeah, you are right. On the M5Stack Grey there is no wiring between the pins. Could you provide some images of the board where one can see how you did the soldering? time to rip my m5stack grey open and do some soldering too :)

    For the next version of the M5Stack there has definitelyto be a wiring between the IMU (mpu9250) and a pin like 35!!



  • Hi @Tristar

    The daughter board with MPU6886 and BMM150 are the same for M5Stack Gray and Fire. So the picture I've attached to my previous post (#15) also applies for M5Stack Gray.

    Good luck!
    Felix

    P.S. you'll find the same information also through the link in my signature below.



  • Hi guys

    Just a heads up on the new M5Core2 which has the IMU and mic on a micro board attached to the M5bus. As far as I can tell the interrupt pin of the MPU6886 doesn't seem to be connected to GPIO35 or any other pin on the M5bus which is a bit disappointing.

    Cheers
    Felix



  • Does anyone know what the trigger values of registers ACCEL_WOM_THR represent? For example, for the ADXL345, 1 LSB of trigger register is the equalavent of 0.065 G. However, there is no information about this in the datasheet of the MPU6886 and the value also seem to be effected by setting a different value for A_DLPF_CFG in the ACCEL_CONFIG_2 register.

    If anyone can help with this that would be nice.



  • @doublep hello, could you refer me to where you read that value from?