Acceleration measurement - ADXL372 ADXL362 - curious peak values

RE: Acceleration measurement - ADXL372 ADXL362 - curious peak values

peng.cheng — Thu, 06 Apr 2023 09:58:03 GMT

Hi Jürgen,

Thanks for your response!

I am working on the ADXL372, but fail to get steady acceleration values.

As I posted here:
https://devzone.nordicsemi.com/f/nordic-q-a/97479/thingy91-adxl372-accel_polling-example-not-giving-proper-data

The values are jumpy, and sometimes there are really big ones, that points me here.

BR,

Peng

RE: Acceleration measurement - ADXL372 ADXL362 - curious peak values

grj — Thu, 06 Apr 2023 09:48:54 GMT

Hi Peng,

sorry but not really.
Unfortunately, it did not work reproducibly either.
The problem has come back with the next compile.

I think however that I possibly come the problem slowly on the trace.

In my while loop in which the acceleration data is recorded, I have built in a sleep function at the end to reduce the sampling frequency:

k_sleep(K_MSEC(5));

Without this sleep function the sampling frequency is too high but the peak values do not occur.
As soon as I insert this sleep function again, the peak values occur again.

I think that the ADXL372 is sometimes not ready to output values after the sleep function.

Regards
Jürgen

RE: Acceleration measurement - ADXL372 ADXL362 - curious peak values

peng.cheng — Thu, 06 Apr 2023 07:38:24 GMT

Hi grj ,

It is a bit confusing for me, seems the issue disappears after you set it to "use global thread" and then back to the original setting "no trigger". But could you explain why this solves the issue? Thanks!

BR,

Peng

RE: Acceleration measurement - ADXL372 ADXL362 - curious peak values

helsing — Mon, 27 Feb 2023 09:09:18 GMT

Hi Jürgen,

Thank you for the update, and sorry for the delay. Great to hear that you found a solution!

Best regards,

Håkon

RE: Acceleration measurement - ADXL372 ADXL362 - curious peak values

grj — Thu, 23 Feb 2023 16:11:56 GMT

Hi Håkon,

I was able to fix the error. It was probably the trigger and the FIFO as you mentioned.

I changed the trigger mode for the ADXL372 to "Use global thread". After compiling I set it back to "No trigger".

And since then these Peak values are gone.

Thanks a lot for your help!

Best regards

Jürgen

RE: Acceleration measurement - ADXL372 ADXL362 - curious peak values

grj — Tue, 21 Feb 2023 10:42:37 GMT

Hi Håkon,

what else I found out, the high peak values are not normally distributed. Here is a simple spectrum that I have created. X is the number of readings and Y is the acceleration in m/s².
That are the peak values I have recieved over the last weeks with both thingys I have.

As a scatter it looks like this:

Values wich are under 196.2 m/s² are not sent by the thingy.

Best regards Jürgen

RE: Acceleration measurement - ADXL372 ADXL362 - curious peak values

grj — Thu, 16 Feb 2023 09:01:24 GMT

Hi Håkon,

thank you for all the explanation and help.

I use both accelerometers in measurement mode and not with activity detection.
We don't want to trigger something at certain events but we want continuous measured values to see which accelerations occur at which time.

That's why I didn't set a trigger.

So FIFO and Activity time don't play a role in my code or am I wrong?
The peak values are always only one measurment.
The time between each measurment is aboout approx.: 5 ms

When the high values with the ADXL372 occuring, there are no conspicuities or trends visible in the values of the ADXL362.

Best regards

Jürgen

RE: Acceleration measurement - ADXL372 ADXL362 - curious peak values

helsing — Wed, 01 Feb 2023 13:11:33 GMT

H Jürgen

[quote user="grj"]since the wrong value is already output by " sensor_value_to_double", the error is more likely to be found in the .config (e.g. a wrong filter) than in the code isn't it?[/quote]

There is probably no mistake in sensor_value_to_double as it is a frequently used function. I spoke to one of our engineers who has experience with the two sensors again. He didn't see that kind of noise in his application, but he used the sensor in a different way that could have masked the issue.

He mentions that it is possible that the sensor needs to be filtered.

Further he suggests, as a next step, to compare the outputs of both sensors. Although more noisy, the ADXL372 should show the same general trends like the ADXL362. In a steady state, we are talking about about 1G downwards (most likely the z axis). He also looked into the driver again and found no obvious bit shifting issues there.

I had a look here and there in the datasheet for ADXL372 and noticed the following about Trigger Mode:

In triggered mode, the FIFO operates as in stream mode until an activity detection event, after which it saves the samples surrounding that event. The operation is similar to a one-time run trigger on an oscilloscope. The number of samples to be saved after the activity event is specified in FIFO_SAMPLES (Register 0x39[7:0], along with Bit 0 in the FIFO_CTL register, Register 0x3A). For example if the FIFO_SAMPLE is set to 12, there are 500 samples before the trigger and 12 after the trigger. The trigger can be reset by clearing the activity interrupt and reading all 512 locations of the FIFO. If this is not complete, future FIFO data reads may contain invalid data. Place the FIFO into triggered mode by setting the FIFO_MODE bits in the FIFO_CTL register (Register 0x3A) to 0b10.

You could try to check the code to verify that the activity interrupt is cleared and that all 512 samples are read?

I also noticed regarding the activity timer:

Activity Timer
Ideally, the intent of activity detection is to wake up a system only when motion is intentional, ignoring noise or small, unintentional movements. In addition to being sensitive to low g events, the ADXL372 activity detection algorithm is robust in filtering out undesired triggers. The ADXL372 activity detection functionality includes a timer to filter out unwanted motion and ensure that only sustained motion is recognized as activity. The timer period depends on the ODR selected. At 3200 Hz and below, it is ~6.6 ms; at 6400 Hz, it is ~3.3 ms. For activity detection to trigger, above threshold activity must be sustained for a time equal to the number of activity timer periods specified in the activity time register. For example, a setting
of 10 in this register means that above threshold activity must be sustained for 66 ms at 3200 Hz ODR. A register value of zero results in single sample activity detection. The maximum allowable activity time is ~1.68 sec (or 841.5 ms at 6400 Hz ODR). Note that the activity timer is operational in measurement mode only.

Are you using any activity timer? What is the duration of the spikes you are seeing?

RE: Acceleration measurement - ADXL372 ADXL362 - curious peak values

grj — Thu, 26 Jan 2023 14:45:48 GMT

Hello Håkon,

since the wrong value is already output by " sensor_value_to_double", the error is more likely to be found in the .config (e.g. a wrong filter) than in the code isn't it?

Have you made any long term measurements with the ADXL372? Have you observed such values before or am I alone with this problem?

Best regards

Jürgen

RE: Acceleration measurement - ADXL372 ADXL362 - curious peak values

helsing — Thu, 26 Jan 2023 14:31:50 GMT

Hi Jürgen,

Sorry, I am not sure if I understand the question correctly. Perhaps you could rephrase it?

Best regards,

Håkon

RE: Acceleration measurement - ADXL372 ADXL362 - curious peak values

grj — Wed, 25 Jan 2023 07:27:21 GMT

Hi Håkon,

I think I now have the values you meant:

I have set a breakpoint in a line if (werthx > 200).

werthx = 516,806

&accel2
val1 = 516
val2 = 805712

Does this mean that it is more likely due to the config?

Best regards
Jürgen

RE: Acceleration measurement - ADXL372 ADXL362 - curious peak values

helsing — Thu, 19 Jan 2023 14:19:27 GMT

Hi Jürgen, sorry for the delay.

Could you try to debug add a breakpoint at line 13? For example, if werthx is larger than 10g, print out what was fed into sensor_value_to_double and compare it to werthx

It would also be interesting to see the raw sensor data directly as they come from the sensor. This way we might learn more about whether there is something wrong with the driver or whether the sensor needs to be set up differently (filtering etc.).

RE: Acceleration measurement - ADXL372 ADXL362 - curious peak values

grj — Thu, 12 Jan 2023 14:10:25 GMT

Hi Håkon,

both sensors are in measuring mode. I read out both of them, and if there is a Value higher than 8g I take the value from the ADXL372 otherwise I take the value from the ADXL362.

With this Values I calculate rms and also send Peak values.

But the high peak values are direct from "sensor_value_to_double" from the ADXL372.

                    if (IS_ENABLED(CONFIG_ADXL372_TRIGGER)) {
                            if (IS_ENABLED(CONFIG_ADXL372_PEAK_DETECT_MODE)) {
                                    printf("Waiting for a threshold event\n");
                            }
                            k_sem_take(&sem, K_FOREVER);
                    } else {
                            if (sensor_sample_fetch(dev2)) {
                                    printf("sensor_sample_fetch failed\n");
                            }
                    }

                    sensor_channel_get(dev2, SENSOR_CHAN_ACCEL_XYZ, accel2);
                    double werthx = sensor_value_to_double(&accel2[0]);
                    double werthy = sensor_value_to_double(&accel2[1]);
                    double werthz = sensor_value_to_double(&accel2[2]);

What would be the disadvantage of the ADXL372 when in measuring mode?

Thanks for the hint with the zephyr's accel polling. I will give it a try.

Best regards

Jürgen

RE: Acceleration measurement - ADXL372 ADXL362 - curious peak values

helsing — Fri, 06 Jan 2023 22:39:30 GMT

Hi Jürgen, sorry for the delay. Here are some of the comments and questions that came up when trying to understand this issue:

Which one of the two motion sensors are we seeing average and peak values from?

Are you using activity detection by manually reading the status register? Are you using the power saving features like instant-on-mode or wakeup-mode? These can be configured in .dts.

ADXL372 is mostly useful for peak detection. It is recommended to use the hardware feature for peak detection along with the trigger. ADXL362 is better suited for measuring subtle movements and average.

Another thing to try is zephyr's accel_polling sample to see if you are able to reproduce the readings. There can always be those easy-to-miss integer-conversion errors in application code.

RE: Acceleration measurement - ADXL372 ADXL362 - curious peak values

grj — Fri, 23 Dec 2022 10:27:02 GMT

Hello Håkon,

Thank you for helping me with this issue.
Would it help if I set the sampling frequency of the 372 higher?

Yes, I am using the zephyr driver.
I found the status flag, but doesn't that mean that only a value is output when the status is ready?

Regarding the temperature sensor, I will measure the consumption. Unfortunately, I won't have the opportunity to measure until next year.

Thank you and best regards
Jürgen

RE: Acceleration measurement - ADXL372 ADXL362 - curious peak values

helsing — Thu, 22 Dec 2022 14:18:08 GMT

Hello Jürgen,

It might be that you are reading peak values before they are ready. There is a flag in the STATUS register which is automatically checked if you are using the Zephyr driver.

I have also received a longer reply form our team with suggestions regarding what this could be. I will provide you with an update later today.

Regarding the temperature, I agree with Achim that this could be due to increased current consumption. It is a good approach to measure the current, for example with PPK2, and compare with the temperature readings.

Best regards,

Håkon

RE: Acceleration measurement - ADXL372 ADXL362 - curious peak values

helsing — Tue, 20 Dec 2022 10:31:10 GMT

Hello Jürgen,

Just letting you know I am working on finding out what this might be and will get back to you.

RE: Acceleration measurement - ADXL372 ADXL362 - curious peak values

grj — Mon, 19 Dec 2022 13:56:42 GMT

Hello Achim,

[quote userid="5203" url="~/f/nordic-q-a/94946/acceleration-measurement---adxl372-adxl362---curious-peak-values/401131"]Does "identical" include the same time? Maybe you live in a earthquake region? Or close to a street with heavy vehicles? Or is it just the signal pattern, but at different times?[/quote]

Thank you for your input. It is definitely not real accelerations (from earthquake or other accelerations) as these peak values are up to 2000 m/s² (the entire measuring range of the ADXL372)
It's more of a noise and it occurs on both Thingys but not at the same time.

[quote userid="5203" url="~/f/nordic-q-a/94946/acceleration-measurement---adxl372-adxl362---curious-peak-values/401131"]I see CONFIG_MQTT_RECONNECT_DELAY_S or CONFIG_LTE_CONNECT_RETRY_DELAY_S. Which one did you test?[/quote]

Sorry, an error has slipped in. The higher temperatures occur in the interval of CONFIG_LTE_CONNECT_RETRY_DELAY_S.
I do not charge the lipo during these tests. But the hint with the current measurement I will try.
I will also look at the temperature compensation of the Asset tracker v2. Thank you very much.

Best regards Jürgen

RE: Acceleration measurement - ADXL372 ADXL362 - curious peak values

Achim Kraus — Sat, 17 Dec 2022 09:05:13 GMT

> The problem is identical for both Thingys.

Does "identical" include the same time? Maybe you live in a earthquake region? Or close to a street with heavy vehicles? Or is it just the signal pattern, but at different times?

> LTE_RECONNECT_DELAY_S

I see CONFIG_MQTT_RECONNECT_DELAY_S or CONFIG_LTE_CONNECT_RETRY_DELAY_S. Which one did you test?

I would use a PPK2 to measure the power consumption. Maybe the culprit is just a higher power consumption, if the device is "connected" for longer or "disconnected" for shorter.

In my experience, the "heater" in a Thingy:91 is mainly the modem, it has the highest current consumption depending on its activation state.

The other "heater" is the LiPo when getting charged. But that's more about 10° than 1°.

The asset tracker v2 offers a

config EXTERNAL_SENSORS_BSEC_TEMPERATURE_OFFSET
   int "BSEC temperature offset in degree celsius * 100"
   default 120 if BOARD_THINGY91_NRF9160_NS
   default 100

to compensate the self heating when using protocols with higher power consumption.