ADXL362 Calibration

[XavierN]

Hello,

We are planning to use the accelerometer in the Thingy91, we have some inconsistent results when configuring/reconfiguring, we have 2 questions:

 - When we, for example, want to change the thresholds while running, we write the values in the corresponding registers, is there anything else to do so the accel starts using the new values? Does the accel need to be reset somehow?

 - See attached a typical sequence of measurments when running the adxl362 sample included with zephyr. The z axis is measuring earths gravitation, but why the other two axis are consistently measuring values around -1.5 m/s^2? This is of course with the device motionless. Does the accel need to be calibrated somehow?

Thank you.

Xavier

[Øyvind]

I'm not sure I follow. 

The default value is 1000 for the the CONFIG_ADXL362_ACTIVITY_THRESHOLD according to our source code, which is the Scale Factor at X_out, Y_out, Z_out. This converts to 2g range (LSB/g), according to ADXL362 datasheet. The value is default at start up if not configured in application (prj.conf or dts), and you should be able to change this to what fits your application either via prj.conf/dts or via sensor API.

CONFIG_ADXL362_ACTIVITY_THRESHOLD is the one that affects the driver and makes the accelerometer_poll() function kick in. From that you get the x,y,z acceleration values and can do processing on that.

Øyvind said:

The thresholds are configured in prj_thingy91_nrf9160ns.conf using:

Fullscreen

I referred to CONFIG_ADXL362_ACTIVITY_THRESHOLD=200 which converts to 0.2g. This is the default value for when using the Thingy:91. Then to change this value during runtime you will need to use sensor_attr_set() and the correct register setting in ADXL362. See zephyr\drivers\sensor\adxl362\adxl362.h for an overview of API calls. 

For more details on how to communicate with the ADXL362, please read the ADXL362 datasheet..

-Øyvind

[XavierN]

I understand that the THRESHOLD is configurable via prj.conf or sensor_attr_set() and I have read the sheet maaaaany times believe me 

What I was trying to get at is that, other than the THRESHOLD, the parameter that determines the behaviour of the trigger is what AD call TIME, ie the number of times that the accelerometer values need to be above/under the threshold for it to fire.

From the data sheet (ACTIVITY TIME REGISTER):

The value in this register sets the number of consecutive samples that must have at least one axis greater than the activity threshold (set by THRESH_ACT) for an activity event to be detected.The time (in seconds) is given by the following equation:Time = TIME_ACT/ODRwhere: TIME_ACT is the value set in this register. ODR is the output data rate set in the FILTER_CTL register (Address 0x2C)

Now, when the initialization of the chip is performed by the driver, the activity threshold is configured here:

https://github.com/nrfconnect/sdk-zephyr/blob/3026111719563ecdc89cf34490cbe9f26c91113f/drivers/sensor/adxl362/adxl362.c#L64

If you examine this call, you will see that the 4th parameter is hardcoded to 1.

In the function definition this 4th parameter that in the call is hardcoded to 1 is received in a variable called "time" as per:

https://github.com/nrfconnect/sdk-zephyr/blob/3026111719563ecdc89cf34490cbe9f26c91113f/drivers/sensor/adxl362/adxl362.c#L395

That parameter called "time" that is hardcoded to 1 is used here to set the ADXL362_REG_TIME_ACT register value:

https://github.com/nrfconnect/sdk-zephyr/blob/3026111719563ecdc89cf34490cbe9f26c91113f/drivers/sensor/adxl362/adxl362.c#L427

Which according to the following line is the register at the address 0x22:

https://github.com/nrfconnect/sdk-zephyr/blob/3026111719563ecdc89cf34490cbe9f26c91113f/drivers/sensor/adxl362/adxl362.h#L44

This is the register that I cited above.

So, for some reason the driver hardcodes that parameter, both for activity and inactivity, to 1.

And hence my question, since we are getting very inconsistent results using this parameter, is there a reason for that parameter to be hardcoded to 1?

[Øyvind]

Hello, 

My apologies for the late reply. I have been OoO for some days. 

Our team have not been able to provide a good answer to why it is set to "1". This originates from the initial commit found here: https://github.com/nrfconnect/sdk-zephyr/commit/8e27ad430edcd5834af5a99977a1baad8a0bcdc6

Kind regards,
Øyvind

[XavierN]

We modified the driver in order for us to be able to modify that value via KCONFIG variables and it seems to work fine. We'll send the changes upstream shortly.

Thank you.

[Øyvind]

That's great news!