Pysense accelerometer wake up issues

[jcaron]

@seb Pull request created: https://github.com/pycom/pycom-libraries/pull/53

[jcaron]

Hi @seb, can you or @jmarcelino or some other member of the team confirm the fact that enabling accelerometer wake up brings the deep sleep power draw to about 380 µA?

I would really love to be able to use a "knock to activate config mode" feature, but while I can probably accept the 50 µA promised by the ST data sheet, 380 µA is just way too much.

If it is indeed 380 µA, any way to reduce that?

I'm wondering if we're not facing the same kind of issue I had when using INT pin wake up on the Pysense, where I ended up cutting the associated pin on the LoPy to make it work reliably.

Let me know what you find out.

Thanks!

[jcaron]

Hi @seb, can you please just confirm that you get the same 380 µA current while in deep sleep with accelerometer wake up enabled?

Thanks!

[seb]

@jcaron

Hi,

I'll add it to my to-do list, I'll get back to you as soon as I can

[seb]

@jcaron

I got @jmarcelino to run the test on his OTII, and the results confirm what you measured:

Average consumption with accel wake disabled: 5.19 μA
With accel wake enabled: 336 μA

[jcaron]

Thanks @seb and @jmarcelino! Don't get exactly the same figures, but we're definitely in the same ballpark.

I'll set this aside for now as I don't quite have the time and it was just a "nice to have" feature, but I suppose this should be investigated further at some point, as the sensor itself should only use 50 µA, not over 300, and it renders the wake-on-accelerometer feature a lot less useful.

A few things that could be explored:

• it could be that keeping the accelerometer powered on means that all the other sensors are powered on as well and it is them using the rest of the current
• it could be the fact that the accelerometer INT pins are set to open drain
• it could be the powered down ESP32 (which looks like it's connected to ground when powered down) sinking current coming from a pull-up somewhere
• or it could be that the data sheet is just plain wrong :-)

[sslupsky]

Hi @jcaron I know you are aware of this but for anyone else coming across this topic, @dmayorquin created a topic that discusses setting the ODR to 0 to keep the deep sleep power consumption under 20uA. As I recall the current consumption of the accelerometer is a function of the ODR. So, reducing the ODR will correspondingly reduce the current. In the case where ODR is 0, the accelerometer is disabled and in its sleep power state.

https://forum.pycom.io/topic/3594/how-to-deep-sleep-with-sipy-pysense-3-7v-lipo

[jcaron]

@sslupsky Setting ODR to 0 will disable the accelerometer, when the whole goal here was to wake up using the accelerometer. Note that power draw is still sub-milliamp, it's just a lot higher than excepted (>300 µA instead of about 50), which drastically reduces battery life...

[dmayorquin]

Hi, I'm trying to wake up my SiPy + Pysense setup by using the accelerometer and I'm experimenting the same issues you tell.

By now I've discovered that if I write

acc.enable_activity_interrupt(1200, 5000)
py.setup_sleep(30)
py.go_to_sleep()

in order to set 5 seconds of inactivity duration, when I measure the current consumption I can see It lowers to ~130 µA (when the boards enter deep sleep mode) by around 5 seconds and then It rises up to ~380 µA. For me, It seems like an issue with pycoproc.py module.

[dmayorquin]

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.