Hello Jonathan, the hardware bias changes (inside calibbias exactly) is due to the noise differences of the 2 modes, introducing a little change in offset (these comes from the MEMS mechanical parts). This change cannot be anticipated sadly. Most of the time, the low power mode is used for accelerometer, since most used accelerometer features are motion monitoring in the background (pedometer, activity, ...). But high frequencies can be needed for very fast event like tap our double taps on the device. We could default to low-power mode and switch to low-noise mode automatically only for the high frequencies where it is mandatory. And we could add a sysfs entry like low_noise_mode to enforce low-noise mode for lower frequencies supporting it. This way traditional userspace can ignore the power_mode setup and use all frequencies. And only specialized userpsace components can set this low_noise_mode to have better noise values for specific use cases. For the hardware bias issue, the high frequency use cases are usually not impacted by the absolute offset, so it should not be a big issue. Is that OK for you? Thanks, JB ________________________________________ From: Jonathan Cameron <jic23@xxxxxxxxxx> Sent: Sunday, May 19, 2024 13:52 To: Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@xxxxxxx> Cc: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>; INV Git Commit <INV.git-commit@xxxxxxx>; lars@xxxxxxxxxx <lars@xxxxxxxxxx>; linux-iio@xxxxxxxxxxxxxxx <linux-iio@xxxxxxxxxxxxxxx> Subject: Re: [PATCH] iio: imu: inv_icm42600: add support of accel low-power mode This Message Is From an External Sender This message came from outside your organization. On Mon, 13 May 2024 09:18:34 +0000 Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@xxxxxxx> wrote: > Hello Jonathan, > > sorry for the patch malformation, I will send a V2 fixed. > > Our chips have usually 2 working modes called "low-noise" and "low-power". > > "Low-noise" is the standard mode where the chip (ADC/MEMS) runs continuously with high precision oscillator. Measures are the best with the less jitter (low noise), you can use the highest possible frequencies (> 500Hz), but power consumption is high, and you cannot use the lowest frequencies (< 12.5Hz). > > "Low-power" is duty cycling the chip, turning ADC and MEMS on only when measuring and then turns it off. Power consumption is then much lower (low power), you can use the lowest frequencies (< 12.5Hz), but measures have more jitter, and you cannot use the highest frequencies. > > Depending on the use case, you may prefer to have the "low-noise" mode with better measures and high frequencies, or the "low-power" mode with less power consumption and low frequencies. The main point is the frequencies availability depending on the power mode. > > We could have the driver switching automatically from low-noise to low-power to support all possible frequencies, but we need to arbitrary choose the mode for the common frequencies, and the configured hardware bias in bias registers are not the same depending on the power mode. We prefer handling all this from userspace, switching the mode when needed depending on the use case and dealing with the 2 sets of hardware bias depending on the modes. > > I hope I am clear enough with my description. > Whilst I understand the motivation, the problem with this is that most userspace software will have no idea what these controls do. It is very challenging to provide enough discoverability to userspace because these modes tend to have weird and wonderful side effects (e.g. the hardware bias here). So I'd very strongly suggest at least a 'default' option to figure it out from the requested frequencies probably defaulting to low noise on the common frequencies - "when in doubt give the best possible data". With that in place, I'd be more likely to be persuaded of the need for a 'tweak' bit of custom ABI that overrides this automatic parameter setting. Thus things would work as well as possible for normal software, and advanced software, by which I mean your userspace stack, would have access to a way to bias the low power / low noise decision in the common frequencies. The sticky bit here is that hardware bias. I'm assuming that is what we are controlling via calibbias? If so is there any sane way to relate the two sets of bias values? Normally (I think) that stuff is about fixing variability in the analog signal part of the device, so I'd expect any change in value to be predictable unless there is something odd going on with digital filtering perhaps? Finally I do wonder how often people use those mid frequencies where there is a direct choice. In broad terms the reason for low power is to do detection of background stuff - screen rotation etc in which case they'd also pick low frequency to save even more power. The low noise modes are for when the precise data matters a lot more and those tend to also need at least moderately high sampling rates because people are typically running some sensor fusion on top and accurate data but at low frequency is usually no good for that unless you know something is mechanically filtering the motion (i.e it's fine on measuring shaft rotation on something with lots of inertial, not so much human motion). Jonathan > Thanks, > JB > > > > ________________________________________ > From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> > Sent: Thursday, May 9, 2024 15:13 > To: INV Git Commit <INV.git-commit@xxxxxxx> > Cc: jic23@xxxxxxxxxx <jic23@xxxxxxxxxx>; lars@xxxxxxxxxx <lars@xxxxxxxxxx>; linux-iio@xxxxxxxxxxxxxxx <linux-iio@xxxxxxxxxxxxxxx>; Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@xxxxxxx> > Subject: Re: [PATCH] iio: imu: inv_icm42600: add support of accel low-power mode > > This Message Is From an External Sender > This message came from outside your organization. > > On Tue, 7 May 2024 10:30:56 +0000 > inv.git-commit@xxxxxxx wrote: > > > From: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@xxxxxxx> > > > > Add channel attributes "power_mode" and "power_mode_available" for > > setting accel power mode (low-noise or low-power). > > > > Differents ODRs and filter are possible depending on the power mode. > > Thus make ODRs and filter dynamic and check values when applying. > Hi Jean-Baptiste > > No Sign-off? > > We have never provided this sort of control because it's near > impossible for user space to know what to do with it. > > Various attempts happened in the past to provide enough info > to userspace, but didn't succeed because what low power means > is incredibly chip dependent. As a general rule everyone wants > low power, but at 0 perf cost :) > > What are the results of low power mode? Normally it maps as > something we can enable when some other set of states is set or > automatically control based on how often the device is being accessed etc. > > For example, what do we loose by choosing this mode for everything > below 200Hz? > > I see there is some reference to 'low noise' - what does that actually > mean for this device? Is it oversampling or running lower resolution on > the ADCs? If so those are the things to look at as ways to control > this. Choose lowest power to meet a given set of requirements. > > Jonathan
