Re: st_lsm6dsx : first two values of ism330dlc_gyro are wrong

[Lorenzo Bianconi <lorenzo@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3950 bytes --]

> On Mon, 6 Feb 2023 10:58:08 +0100
> Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> 
> > > On Sun, 5 Feb 2023 11:12:23 +0100
> > > Philippe De Muyter <phdm@macq.eu> wrote:
> > >   
> > > > Hello Lorenzo and list,
> > > > 
> > > > I use the imu/st_lsm6dsx (i2c) driver to drive a ism330dlc imu.
> > > > 
> > > > Every time I start a new acquisition of gyro values, the first two
> > > > values read are wrong, as can be see here :
> > > > 
> > > >  $ sudo ./iio_generic_buffer -n ism330dlc_gyro -g -c 10 -a
> > > >  iio device number being used is 1
> > > >  trigger-less mode selected
> > > >  No channels are enabled, enabling all channels
> > > >  Enabling: in_anglvel_z_en
> > > >  Enabling: in_timestamp_en
> > > >  Enabling: in_anglvel_y_en
> > > >  Enabling: in_anglvel_x_en
> > > >  -0.138924 -0.915246 0.470628 1675591514696125669
> > > >  -0.012699 -0.362151 0.143208 1675591514772675669
> > > >  0.001989 -0.076500 0.035190 1675591514849250669
> > > >  0.002295 -0.076194 0.035343 1675591514925825669
> > > >  0.002142 -0.076041 0.035343 1675591515002400669
> > > >  0.001989 -0.076041 0.035343 1675591515078975669
> > > >  0.001836 -0.076347 0.035649 1675591515155525669
> > > >  0.001836 -0.076500 0.035649 1675591515232075669
> > > >  0.001989 -0.076500 0.035649 1675591515308625669
> > > >  0.001989 -0.076347 0.035649 1675591515385200669
> > > >  Disabling: in_anglvel_z_en
> > > >  Disabling: in_timestamp_en
> > > >  Disabling: in_anglvel_y_en
> > > >  Disabling: in_anglvel_x_en
> > > >  $
> > > > 
> > > > Is that a normal behaviour for a gyro in that family or is it be caused
> > > > by a software or hardware bug ?  
> > > 
> > > So, some random thoughts on what might be going on...
> > > 1) Stale data in the fifo.  Could you run this experiment twice whilst being
> > >    careful not to move the device between the runs.  If we still see the wrong
> > >    values at the start then it's not that...  
> > 
> > When the device is powered-down we set the FIFO in bypass mode and in-flight
> > samples are discarded.
> > 
> > > 
> > > 2) Device takes a little whilst to stabilize. Possibly this is down to the
> > >    low pass filters requiring a few samples before they deliver stable output.
> > >    From a quick glance I don't think we provide any userspace control of those
> > >    filters and I think LPR1 is left in default state of disabled.  
> > 
> > I would say this issue is related to the "Accelerometer and gyroscope
> > turn-on/off time" (section 3.9 in the sensor application note).
> > 
> > https://www.st.com/resource/en/application_note/an5125-ism330dlc-3d-accelerometer-and-3d-gyroscope-with-digital-output-for-industrial-applications-stmicroelectronics.pdf
> > 
> > @Jonathan: do you think we should discard these sample in the driver or in the
> > user-space app? I would say this can be a general issue. What do you think?
> 
> In driver.  This isn't an uncommon problem for sensors and userspace would in 
> general have no idea how many samples to drop.  Also dependent on the sampling
> rates etc so if we support control of those, we'll want to have the driver
> drop the right number of samples.  Though yikes at the top end. You can have
> to drop 540 samples... Ah well. That is at 6kHz sampling so still not very long.
> 
> The only alternative would be to expose the current number to drop to userspace
> but then existing userspace code would not drop them.  Hence I think it needs
> to be in driver.

ack, I will work on it.

Regards,
Lorenzo

> 
> Jonathan
> 
> 
> > 
> > Regards,
> > Lorenzo
> > 
> > > 
> > > You could try messing with the sampling frequency as that may affect the number
> > > of bad samples you see and give us more of a clue (it affects lpf2 directly).
> > > 
> > > Jonathan
> > >   
> > > > 
> > > > Best regards
> > > > 
> > > > Philippe
> > > >   
> > >   
> > 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]