ADXL362 sensor includes 1g for gravity

[coderbyheart]

This leads to the activity chart being skewed (the sum of all axis always includes 1g / 9.80665m/s²).

• [ ] Update the documentation and description in protocol definition
• [ ] Subtract 1g from values printed in charts

ADXL362.pdf

[coderbyheart]

This creates a bit of a problem around the Accelerometer threshold (acct). This is a cut-off value where all motion below this threshold should be ignored, however, given that the reading always includes 1 g, the logic in the firmware needs to be changed:

If acct is 10, a movement of 1 m/s² in direction of the Z axis (down) will be registered (because the sensor will report 1 g + 1 m/s² >= 10 m/s²), however a movement with the same acceleration against the direction of the Z axis (up) will not be registered (because the sensor will report 1 g - 1 m/s² < 10 m/s²).

I think the way the firmware handles the threshold needs to be changed:

1. there is a user-defined per-axis threshold which has the problem that it's not possible to filter out the 1 g, it will always be present on some axis. If a users sets acct to 10, as shown above, the axis along gravity can easily trigger, but for the other two axis the same threshold will lead to much fewer triggers (they have to register motion above 1 g).
2. the calculation of the total motion considers each axis individually and does not subtract 1 g to get a relative motion.

This problem is also described in the ADXL362 documentation:

In many applications, it is advantageous for activity detection to be based not on an absolute threshold, but on a deviation from a reference point or orientation. This is particularly useful because it removes the effect on activity detection of the static 1 g imposed by gravity. When an accelerometer is stationary, its output can reach 1 g, even when it is not moving. In absolute activity, when the threshold is set to less than 1 g, activity is immediately detected in this case.

It sounds like the better way to use the ADXL362 for the cat tracker is to use in the "Referenced Configuration" mode.

@simensrostad @jtguggedal what do you think?

[simensrostad]

Hi, this sounds reasonable. But I thought we were already using reference mode in the firmware. CONFIG_ADXL362_ABS_REF_MODE set to 1.

[coderbyheart]

It doesn't look like it, because

1. a per-axis threshold is set
2. the sensor returns values that include 1 g, otherwise the sensor chart would not have all values above 10

[jtguggedal]

I agree that the threshold logic in the firmware should be revisited. The challenge is that we don't know which axis or axes contain gravity, and how large a component it is for each axis.

I think referenced mode is used for Thingy:91: https://github.com/nrfconnect/sdk-nrf/blob/ea7f385f96e6e8f760a6d8a081be761ed42c2ff8/applications/asset_tracker_v2/boards/thingy91_nrf9160ns.conf#L19

From the datasheet, 1 should mean referenced mode:

The way I read the documentation, is that the referenced mode is used only for the (in)activity detection, while the values that are read out still contain gravity.

Regarding the per-axis thresholds, I don't think we need to set those, as they all seem to map to the same registers, (IN)THRESH_ACT_L / (IN)THRESH_ACT_H. It's a bit confusing that the driver doesn't accept SENSOR_CHAN_ACCEL_XYZ, so that's probably something we could add upstream. https://github.com/nrfconnect/sdk-zephyr/blob/73a419c5d7d60d9e476dfee62669e96236601755/drivers/sensor/adxl362/adxl362.c#L323

[bjda]

I had a look in the app and driver, and the interface might be a bit misleading:

1. The per-axis threshold is really a single threshold; the driver ignores the channel when setting it. This threshold is relevant for both referenced and absolute mode.

2. Referenced mode triggering != referenced data. An internal reference (I am guessing the last inactivity triggering value or a long-term average) is used in the sensor for motion detection and dictates when the interrupt is fired, but the application-level filter compares the absolute values (which are the only externally readable values) to the threshold. In other words, this filter does not really make sense when using referenced mode.

As far as I can see, there is no way to separate activity and inactivity triggers without a change to the driver, which is unfortunate. That binary state is probably the most useful data point from the accelerometer

EDIT: got ninja'd by JT there, but the points stand

[simensrostad]

I had a look in the app and driver, and the interface might be a bit misleading:

1. The per-axis threshold is really a single threshold; the driver ignores the channel when setting it. This threshold is relevant for both referenced and absolute mode.

Yes, sadly I overlooked this part when I made the implementation in the app. However, this shouldn't change anything.

2. Referenced mode triggering != referenced data. An internal reference (I am guessing the last inactivity triggering value or a long-term average) is used in the sensor for motion detection and dictates when the interrupt is fired, but the application-level filter compares the absolute values (which are the only externally readable values) to the threshold. In other words, this filter does not really make sense when using referenced mode.

• This purpose of this filter is to avoid propagating events triggering on inactivity, which is the case for linked mode.

• The specification states that in our case (linked and reference mode) the reference is set when inactivity is detected and activity detection begins

[coderbyheart]

We concluded to eventually remove the reporting of the accelerometer data to the cloud, because it provides no meaningful value for analysis if sent as singular events and sending them continuously would use too much data. Instead the firmware should send an event whenever the "in motion" state of the tracker changes. That way activity can be visualized: the cat is considered active after an "in motion" event has been received until an "not in motion" event has been received. The ADXL362 will be configured to yield these events.

[coderbyheart]

This is not fixable, so it will be solved via #175