Re: st_lsm6dsx : first two values of ism330dlc_gyro are wrong

[Lorenzo Bianconi <lorenzo@kernel.org>]

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

> 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?

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 --]