Hi Jonathan, it makes sense indeed, using a value in m/s2 per second and computing the corresponding threshold based on the sampling frequency. Just that this will be a check against the absolute value of accel, no sign supported. That's why I was thinking about magnitude more than threshold. It will effectively be more complex to handle because it will depend on the sampling frequency and will require to adapt the threshold value when changing sampling frequency. I will rework this series to switch to ROC instead. Thanks, JB From: Jonathan Cameron <jic23@xxxxxxxxxx> Sent: Sunday, March 3, 2024 17:44 To: INV Git Commit <INV.git-commit@xxxxxxx> Cc: lars@xxxxxxxxxx <lars@xxxxxxxxxx>; linux-iio@xxxxxxxxxxxxxxx <linux-iio@xxxxxxxxxxxxxxx>; Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@xxxxxxx> Subject: Re: [PATCH 0/4] Add WoM feature as an IIO event On Sun, 25 Feb 2024 16: 00: 23 +0000 inv. git-commit@ tdk. com wrote: > From: Jean-Baptiste Maneyrol <jean-baptiste. maneyrol@ tdk. com> > > Add WoM (Wake-on-Motion) feature for all chips supporting it > (all except MPU-6000/6050/9150). ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd On Sun, 25 Feb 2024 16:00:23 +0000 inv.git-commit@xxxxxxx wrote: > From: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@xxxxxxx> > > Add WoM (Wake-on-Motion) feature for all chips supporting it > (all except MPU-6000/6050/9150). WoM compares the magnitude of > the current accel sample with the previous one against a threshold > and returns an interrupt event if the value is higher. > > Report WoM as an accel mag_adaptive_rising IIO event, add system > wakeup functionality if WoM is on and put the chip in low-power > mode when the system is suspended. WoM threshold value is in SI > units since the chip is using an absolute value in mg. Adaptive thresholds are normally used when a threshold is based on some offset form a heavily filtered version of the same channel (often with filter resets and other nastiness) It's an obscure hack we added because we couldn't really get these to fit with another scheme. This seems simpler than that from your description. As it's just against the previous reading and I assume the chip is in a self clocking mode during this, it might be more appropriate to use a Rate of Change Event (ROC). There are references to this being a threshold on highpassed sample, so I guess there might be some filtering to make this messier? The control of a roc threshold will be a little more complex as you'll need to take into account the sampling frequency. Advantage is you end up with something easily human understandable. A human doesn't want to have to figure out what the right value is for the particular frequency they are sampling at. Jonathan > > > Jean-Baptiste Maneyrol (4): > iio: imu: inv_mpu6050: add WoM (Wake-on-Motion) sensor > iio: imu: inv_mpu6050: add WoM event inside accel channels > iio: imu: inv_mpu6050: add new interrupt handler for WoM events > iio: imu: inv_mpu6050: add WoM suspend wakeup with low-power mode > > drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 523 +++++++++++++++--- > drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 33 +- > drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c | 17 +- > drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c | 70 ++- > 4 files changed, 541 insertions(+), 102 deletions(-) >
