Linux IIO development
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Philippe De Muyter <phdm@macq.eu>
Cc: lorenzo@kernel.org, linux-iio@vger.kernel.org
Subject: Re: st_lsm6dsx : first two values of ism330dlc_gyro are wrong
Date: Sun, 5 Feb 2023 14:13:42 +0000	[thread overview]
Message-ID: <20230205141342.10dbc447@jic23-huawei> (raw)
In-Reply-To: <20230205101223.GA10729@frolo.macqel>

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

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.

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
> 


  reply	other threads:[~2023-02-05 13:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-05 10:12 st_lsm6dsx : first two values of ism330dlc_gyro are wrong Philippe De Muyter
2023-02-05 14:13 ` Jonathan Cameron [this message]
2023-02-05 15:22   ` Philippe De Muyter
2023-02-06  9:58   ` Lorenzo Bianconi
2023-02-06 14:33     ` Jonathan Cameron
2023-02-06 14:37       ` Lorenzo Bianconi
2023-02-07 23:33       ` Lorenzo Bianconi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230205141342.10dbc447@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=lorenzo@kernel.org \
    --cc=phdm@macq.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox