Wrong x,y and z first sample for LIS331DLH after configuration change?

[RAbra.2]

I am using a LIS331DLH accelerometer chip and I have seen that when I change its configured sometimes I get double value for x, y and z but only for the first sample. Do I need to discard the first sample after configuration change like some other chips?

I am changing from 2G to 8G configuration and sample is as follows:

1st sample:

x: 26

y: 8

z: 521

2nd sample onwards:

x: 13 (+- 5)

y: 1 (+- 5)

z: 261 (+- 5)

[Eleon BORLINI]

Hi @RAbra.2​ , this should not be the case... Did you try with setting the Block data update (BDU) bit in register CTRL_REG4 (23h)? This sets the output registers not updated between MSB and LSB reading. Well when do you perform the self test it is always suggested to discard the first sample, but not in the normal mode running. If however you can afford to discard the first sample after the power on, especially if you uses high ODRs, you could discard the first value or at least apply on it a moving average. Regards

[RAbra.2]

HI @Eleon BORLINI​ 

We are setting BDU bit in CTRL_REG4. Here is our CTRL_REG4 configuration:

CTRL_REG4.bits.BDU = 1;

CTRL_REG4.bits.BLE = 0;

CTRL_REG4.bits.FS = target_fullscale_selection;

CTRL_REG4.bits.STsign = 0;

CTRL_REG4.bits.ST = 0;

CTRL_REG4.bits.SIM = 0;

As you can see only FS bits are changeable in our configuration. We cannot apply a moving average at it this moment in our project as it might impact the scope but we can afford to discard the first sample if it is the only solution available. Kindly confirm.

NOTE: In all configuration we are using ODR = 50 Hz.

Regards

[RAbra.2]

@Community Admin​  @Eleon BORLINI​ 

Can you please provide a confirmation on the above?

Regards

[Eleon BORLINI]

Hi @RAbra.2​ , I suggest you to refer to the online C drivers on Github, lis331dlh_reg.c. The BDU bit can be managed as follows:

/**
  * @brief  Block data update.[set]
  *
  * @param  ctx         read / write interface definitions(ptr)
  * @param  val         change the values of bdu in reg CTRL_REG4
  *
  */
int32_t lis331dlh_block_data_update_set(stmdev_ctx_t *ctx, uint8_t val)
{
  lis331dlh_ctrl_reg4_t ctrl_reg4;
  int32_t ret;
 
  ret = lis331dlh_read_reg(ctx, LIS331DLH_CTRL_REG4, (uint8_t*)&ctrl_reg4, 1);
  if(ret == 0) {
    ctrl_reg4.bdu = val;
    ret = lis331dlh_write_reg(ctx, LIS331DLH_CTRL_REG4,
                              (uint8_t*)&ctrl_reg4, 1);
  }
  return ret;
}
 
/**
  * @brief  Block data update.[get]
  *
  * @param  ctx         read / write interface definitions(ptr)
  * @param  val         change the values of bdu in reg CTRL_REG4
  *
  */
int32_t lis331dlh_block_data_update_get(stmdev_ctx_t *ctx, uint8_t *val)
{
  lis331dlh_ctrl_reg4_t ctrl_reg4;
  int32_t ret;
 
  ret = lis331dlh_read_reg(ctx, LIS331DLH_CTRL_REG4, (uint8_t*)&ctrl_reg4, 1);
  *val = ctrl_reg4.bdu;
 
  return ret;
}

Btw, if you can discard the first sample of the acquisition, I suggest you to do this (this is in general a good practice, because the first data samples could be affected by startup effects both electrical and mechanical that may be due to the environment).

Regards

[RAbra.2]

@Eleon BORLINI​ 

Thank you for the information. We shall proceed accordingly.

Regards