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]

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

The thresholds are configured in prj_thingy91_nrf9160ns.conf using:

CONFIG_ADXL362_ACTIVITY_THRESHOLD=200
CONFIG_ADXL362_INACTIVITY_THRESHOLD=200

In order to configure these thresholds during runtime, you will need to use the Sensor API to send commands to the ADXL362. Have a look at the ADXL362 drivers, and especially adxl362_attr_set().

Found under: zephyr\drivers\sensor\adxl362\

You can also have a look at our Asset_Tracker sample (nrf\applications\asset_tracker\src\motion\motion.c) to see how they communicate with the sensor. 

The device drivers are lacking some documentation, but is work in progress. Let me know if anything is unclear. 

Kind regards,
Øyvind

[XavierN]

We have been looking at the codebases that you mention and as we understand it there is a hardcoded parameter in the driver. In particular when configuring the thresholds you can set the thresholds themselves but also what the documentation calls "time" which is the amount of events above the threshold that need to be measured for it to trigger. That value is hardocded in the driver to 1. We have been testing to change it with various degrees of success, we don't seem to be able to get consistent results. Is there a reason why that particular parameter is hardcoded or it's just as you said a work in progress?

[Øyvind]

My apologies, I see that I have referred to the wrong function to use. According to our apps team, you should be using sensor_attr_set(), which exposes adxl362_attr_set() here: https://github.com/nrfconnect/sdk-zephyr/blob/a3a6410b55fa97a9c6400c37d362c9137c5050b6/drivers/sensor/adxl362/adxl362.c#L624

XavierN said:

We have been testing to change it with various degrees of success, we don't seem to be able to get consistent results.

 Can you provide me with a code snippet of how you are changing? Are you getting an error?

XavierN said:

Is there a reason why that particular parameter is hardcoded or it's just as you said a work in progress?

 Can you please provide me with what particular parameter you are referring to? The sensor documentation in Zephyr is work in progress, adding a device driver index. Currently, the only documentation on device drivers is to read through the source code. Making this a little more complicated at the moment.

But we will find the solution. 

Kind regards,
Øyvind

[XavierN]

In particular I am referring to this change:

https://github.com/nrfconnect/sdk-zephyr/compare/v2.3.0-rc1-ncs1-branch...parkme24:p24-branch

We needed to add the time_act an time_inact parameters ourselves.

[Ø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?