Accelerometer sample question

dajtxx · May 10, 2021

Hi,

I’m getting some data from the accelerometer but am not sure how to interpret it:

#519 @ 1040637 ms: x -0.306432 , y 0.842688 , z -9.882432

If I move the board roughly 90deg as the datasheet says I get the readings moving between the axes, so I can get the +-9 to move to the x or y axis, etc. So that all seems good.

But the above readings are with the board sitting on my desk. So does -9.8… equate to 1g? And why are there non-zero values on x & Y when the board is not moving? Do I need to put some code in to add offsets for manufacturing or something?

To get the sample working I had to enable floating point support on the MCU and use newlib so the double values could be printed out. I also changed the setup of the sensor using guiconfig to have no trigger so it’s being polled by the code because I was getting constant reboots with the trigger enabled.

jaredwolff · May 10, 2021

dajtxx But the above readings are with the board sitting on my desk. So does -9.8… equate to 1g?

The measurements are in m/s². 1g = 9.80665 m/s²

And why are there non-zero values on x & Y when the board is not moving? Do I need to put some code in to add offsets for manufacturing or something?

XY are never going to be perfect zero. They could be offset by a small amount in either the positive or negative direction.

To get the sample working I had to enable floating point support on the MCU and use newlib so the double values could be printed out. I also changed the setup of the sensor using guiconfig to have no trigger so it’s being polled by the code because I was getting constant reboots with the trigger enabled.

Yea, I’m aware of this, turns out the driver was changed along the way and now requires two pins to be defined for interrupts (even if there’s only one connected!) I opened up a ticket on the Zephyr repolast week: https://github.com/zephyrproject-rtos/zephyr/issues/34794

Easiest solution for now is to pick another pin that you’re not using as the INT2 pin in your .overlay file.

&i2c1 {
	lis2dh@18 {
		compatible = "st,lis2dh";
		label = "LIS2DH";
		reg = <0x18>;
		irq-gpios = <&gpio0 29 GPIO_ACTIVE_HIGH>, <&gpio0 30 GPIO_ACTIVE_HIGH>;
	};
};

mlYallow · Feb 28, 2023

Hi, @jaredwolff . Regarding the solution you have suggested above. Is it correct that interrupts will not work since INT2 pin is not connected? Tried to set up triggers and sensor_attr_set fails and return -134.

Is guess my question is related to this post: https://community.jaredwolff.com/d/81-accelerometer-threshold-trigger

In advance thank you,
Kind Regards!

jaredwolff · Feb 28, 2023

@mlYallow

Both interrupt pins are/can be connected. Here’s a snippet from the schematic:

INT1 is, by default, connected. INT2 is the opposite. If you need it simply solder the jumper that’s on the bottom of the board. I believe it’s been like this since V3 of the board.

mlYallow · Mar 1, 2023

jaredwolff Thank you for the reply! I use the SparkFun Thing nRF9160 Thing Plus which unfortunately does not have this option. Am I correct to think that the only way to get interrupt to work on the SparkFun board is to manually solder the INT2 pin to the nRF9160 - P0.29 pin?

Best Regards

jaredwolff · Mar 1, 2023

mlYallow what type of interrupt are you trying to configure. I know the LIS2DH is fairly flexible on how you can use the interrupt pins. (in some ways, redundant). The driver is not as flexible though. :\

mlYallow Am I correct to think that the only way to get interrupt to work on the SparkFun board is to manually solder the INT2 pin to the nRF9160 - P0.29 pin?

P0.29 is one option. It may be tough to get to since the pads are underneath the LIS2DH though.

mlYallow · Mar 2, 2023

jaredwolff I’ve been trying to set the “SENSOR_ATTR_UPPER_THRESH” and/or “SENSOR_ATTR_LOWER_THRESH” alternatively using the "SENSOR_TRIG_DELTA, as I want movement to trigger the system into a different state. The plan is to connect a display that I want to wake up when the accelerometer detects movement.

Yeah, soldering on pads that are underneath the LIS will turn out difficult, hehe.

jaredwolff · Mar 4, 2023

Yea, unfortunately you’ll have to configure the INT1_CFG register manually or modify the driver.

AchimKraus · Apr 16, 2023

Just some remarks from my current experience with ncs 2.3.0 / zephyr v3.2.99-ncs2:

The bindings introduce a “anym-on-int1” flag, which allows to route the SENSOR_TRIG_DELTA also to int1. With that you need to define only 1 gpio for interrupt mapping.

The SENSOR_TRIG_DELTA seems to enable mainly the threshold interrupts. Though you already recognized, one axis may show pretty large values, a large threshold is usually used. Otherwise the threshold interrupt will fire permanently, But that large threshold makes it also less sensitive. The documentation explains the functions in more details.

Luckily the LIS2DH12 supports also a “REFERENCE” and “High pass filter”. To use it , you need to enable CONFIG_LIS2DH_ACCEL_HP_FILTERS and use

struct sensor_value filter = {
          .val1 = 1,
          .val2 = 0,
      };

   rc = sensor_attr_set(accelerometer_dev, SENSOR_CHAN_ACCEL_XYZ,
                           SENSOR_ATTR_CONFIGURATION,
                           &filter);

That will still not be the wanted behavior for motion, because the filter should be frequently reset.
The driver unfortunately does support that out of the box (maybe worth to extend).
I put some extra lines in my application:

...
#include <zephyr/drivers/i2c.h>
...
#define LIS2DH_REG_CTRL2 0x21
static const struct i2c_dt_spec accelerometer_i2c_spec = I2C_DT_SPEC_GET(DT_ALIAS(accelerometer_sensor));
...

      rc = i2c_reg_update_byte_dt(&accelerometer_i2c_spec, LIS2DH_REG_CTRL2, 0xc0, enable ? 0xc0 : 0);
      if (rc) {
         LOG_ERR("Accelerometer error: could not enable autoreset high-pass filter for device %s, %d / %s",
                 accelerometer_dev->name, rc, strerror(-rc));
      }

      value.val1 = enable ? 1 : 0;
      rc = sensor_attr_set(accelerometer_dev, SENSOR_CHAN_ACCEL_XYZ,
                           SENSOR_ATTR_CONFIGURATION,
                           &value);
      if (rc) {
         LOG_ERR("Accelerometer error: could not set high-pass filter for device %s, %d / %s",
                 accelerometer_dev->name, rc, strerror(-rc));
      }

With that I get the result I was expecting “motion detection”.

(Edit: not using LIS2DH_REG_CTRL2 may also result in useful behavior, just check, if that fits for you as well.)

Hope it helps.

mlYallow · May 26, 2023

jaredwolff Hi again I’ve got the new CircuitDojo feather9160 board and soldered the JUMP3 pad. I have decided that I want to read the accelerometer once every second, which as far I understand, corresponds to the accelerometer sample provided. What confuses me is that the trigger is not getting triggered, and stays in the while loop, see below.

    printf("Waiting for triggers\n");
    while (true)
    {
        k_sleep(K_MSEC(2000));
    }

I’m not getting any errors when running the code, here is the serial output:
Booting Zephyr OS build v3.2.99-ncs2 ***
Sampling at 1 Hz
Waiting for triggers

Am right to expect a reading from the accelerometer once every second?

In advance, thank you.
Kind Regards.

AchimKraus · May 26, 2023

printf("Waiting for triggers\n");
while (true)
{
    k_sleep(K_MSEC(2000));
}

There is no magic in that. It sleeps for 2s in a endless loop. It just prevents the app from exit.

The magic for the accelerometer is in

rc = sensor_trigger_set(sensor, &trig, trigger_handler);

that registers an callback trigger_handler, which is then called, when the LIS2DH reports an event via the IO pins and these pins are configured for that interrupt. When that callback is executed, it calls

static void trigger_handler(const struct device *dev,
                            const struct sensor_trigger *trig)
{
    fetch_and_display(dev);
}

and that display then the values.

    if (rc < 0)
    {
        printf("ERROR: Update failed: %d\n", rc);
    }
    else
    {
        printf("#%u @ %u ms: %sx %f , y %f , z %f\n",
               count, k_uptime_get_32(), overrun,
               sensor_value_to_double(&accel[0]),
               sensor_value_to_double(&accel[1]),
               sensor_value_to_double(&accel[2]));
    }

at the end of fetch_and_display should then print at least an error.
Otherwise, I would guess, either the interrupt isn’t configured well (e.g. nRF9160 pin 29 for data ready, but nRF9160 pin 30 wired to LIS2DH int1 which is then the default event for that “data_ready”), or some other issue with the configuration prevents the callback from being called, e.g.

CONFIG_LIS2DH_TRIGGER_NONE=y

instead of

CONFIG_LIS2DH_TRIGGER_GLOBAL_THREAD=y

A very first shot, it may work or not, would be to use exchanged pins in the overlay, e.g. instead of

iq-gpios = <&gpio0 29 GPIO_ACTIVE_HIGH>, <&gpio0 30 GPIO_ACTIVE_HIGH>;

iq-gpios = <&gpio0 30 GPIO_ACTIVE_HIGH>, <&gpio0 29 GPIO_ACTIVE_HIGH>;

mlYallow · May 26, 2023

AchimKraus

Thanks for the swift reply!

Just changed the pins as you suggested and it worked.

I get the other parts you explained above but could you explain why changed the pins resulted in it working? Wouldn’t both pin 29 and 30 be valid irq pins that could trigger the accelerometer?

Kind regards,
and again, thank you

AchimKraus · May 26, 2023

The schematics shows on page 3 the wiring.

nRF9160 pin 30 <– JMP 1 — LIS2DH INT 1
nRF9160 pin 29 <– JMP 3 — LIS2DH INT 2

The LIS2DH documentation explains, how the events (e.g. “data ready” or “any motion/threshold”) are then mapped/configured to the INT1 or INT2 pins. The driver (I analyzed that some weeks ago) maps these events by default:

data-ready => INT1
any-motion => INT2

With that, “data-ready” is
LIS2DH INT1 – JMP 1 —> nRF9160 pin 30

and bindings then explains:

The INT1 and (optional) INT2 signal connections.

With that,

iq-gpios = <&gpio0 29 GPIO_ACTIVE_HIGH>, <&gpio0 30 GPIO_ACTIVE_HIGH>;

maps pin 29 to the “data ready” event, but physically it’s connected to pin 30.

iq-gpios = <&gpio0 30 GPIO_ACTIVE_HIGH>, <&gpio0 29 GPIO_ACTIVE_HIGH>;

maps then the defaults of the LIS2DH driver to the current wiring.

If you add the “anym-on-int1”, you even don’t need JMP3. Then the LIS2DH reports both, “data-ready” and “any-motion” on INT1, which is wired to PIN30 and all works without modification.

jaredwolff · May 26, 2023

Thanks AchimKraus

intelcomdk · Jun 9, 2023

I think the .overlay file in the sample program should be changed to:
irq-gpios = <&gpio0 30 GPIO_ACTIVE_HIGH>, <&gpio0 29 GPIO_ACTIVE_HIGH>;
because according to the schematics for feather V5, INT1 is connected to P0.30 and INT2 is (via jmp3) connected to P0.29

intelcomdk · Jun 9, 2023

AS a “nice to have” the codesnippet from the zephyr sample count be added also, allowing the temperature to be read, I have testet that i works.

intelcomdk · Jun 9, 2023

if (IS_ENABLED(CONFIG_LIS2DH_MEASURE_TEMPERATURE)) {
	if (rc == 0) {
		rc = sensor_channel_get(sensor, SENSOR_CHAN_DIE_TEMP, &temperature);
		if (rc < 0) {
			printf("\nERROR: Unable to read temperature:%d\n", rc);
		} else {
			printf(", t %f\n", sensor_value_to_double(&temperature));
		}
	}

} else {
	printf("\n");
}

AchimKraus · Jun 11, 2023

I think the .overlay file in the sample program should be changed to:

That depends on what should be achieved. If that should support a “unmodified feather v5”, I think,

     lis2dh: lis2dh@18 {
		/* changed in v5 */
		irq-gpios = <&gpio0 30 GPIO_ACTIVE_HIGH>;
		anym-on-int1;
	};

as version specific definition will be the right one. Maybe adding

irq-gpios = <&gpio0 30 GPIO_ACTIVE_HIGH>, <&gpio0 29 GPIO_ACTIVE_HIGH>;

as comment addressing JMP 3.

allowing the temperature to be read,

The question is more, what “the temperature” really represents. The nRF9160 has a temperature as well (“AT%XTEMP?”), but in my opinion none of them provide the value of a real temperature sensor.

jaredwolff · Jun 13, 2023

The temperature on the LIS2DH supposedly does output a temperature but it’s with a 25 degree offset. So 25 - (your reading) should get you the actual temp. I’ve only tested this across a few different devices. There was one device that was giving some weird values. So IMO better to use something more reliable/dedicated.

AchimKraus · Jun 13, 2023

The question is more, what “the temperature” really represents.

The point is more, it represents the temperature of that chip, which may depend on the current consumption and self heating. For the LIS2DH that maybe acceptable, but it’s more a general topic. If you want the temperature of something (e.g. environment) a extra sensor is more accurate. With the newer zephyr versions, one-wire got supported and that makes using a cheap temperature sensor (DS18B20) possible.
And if someone doesn’t care too much, the modem’s temperature does it as well.