cancel
Showing results for 
Search instead for 
Did you mean: 

LIS2MDL Z-axis Noise Issue

MSend
Associate II

Hello and thank you for your help ahead of time.

I am working on a vehicle detection product using the LIS2MDL and noticed a strange anomaly with the Z-axis when I was testing for stability over temperature. Showm in the attached photo, the Z-axis randomly become very noisy until i moved a piece of ferrous metal near the sensor, at which point it stopped. It was only the z-axis too, all others remained very stable as can be seen in the graph. It should also be noted that this behavior was rare and doesn't happen every time im evaluating the stability. This behavior is very undesirable if it would happen randomly on the final product.

Any idea on what could be causing this? Could the Pin 5 Capacitor trace length cause this? Any ideas are greatly appreciated.

Thanks again for your help.

1 ACCEPTED SOLUTION

Accepted Solutions
MSend
Associate II

Well I figured it out. The data on my graph wasn't the RAW value of the axis as I thought, but an average of the last 20. I then also discovered i was running the ODR at 100 hz when my system would only be able to access it at about 60Hz. After lowering the ODR to 50hz and turning on the BDU function, the data errors disappeared. It appeared i was getting bad data somehow and it was shifting my readings by 255 points which caused the lower magnitude noise in my averaging values.

Thanks again for your help Eleon.

View solution in original post

5 REPLIES 5
Eleon BORLINI
ST Employee

Hi @MSend​ , a couple of questions about you test: which are the unit measures of the axis? In case the y-axis value are "°C", please note that the LIS2MDL sensor is guaranteed inside -40°C to +85°C range. Moreover, bad Z-axis behavior occur after a certain time from the temperature change: is your test environment (un)controlled in humidity? Btw, when the read value exceeds a certain threshold you can try as a patch a sw reset (CFG_REG_A reg, procedure at p. 17 of AN5069) of the device or to enable and disable the self-test (CFG_REG_C reg). Regards

MSend
Associate II

Hi Eleon and thank you for the response.

The X-axis is showing time(in hours) and the Y-axis is showing a snapshot of the LIS2MDL's data output every second. That means the lowest temperature here is around 5 Degree C. This test was performed in a temperature controlled chamber with the sensor in a sealed plastic injection molded housing. I do not believe the chamber humidity controlled. At first I thought it may have been something local to the temperature chamber but I was able to observe this happening when i bought the sensor out and had it elsewhere.

Would performing the sw reset help alleviate this issue? Should one be performed every so often?

Thanks again.

Edit: Do you think its possible for two LIS2MDL's in close proximity to adversely affect each other? In my test, there were two prototypes located within 6 inches of each other.

MSend
Associate II

Attached is a photo of the board layout around the LIS2MDL. Y1 is a crystal oscillator, any chance it could be part of the problem? What confuses me is the fact that it is very inconsistent with when it occurs and their doesn't seem to be anything in particular causing it too occur.

Eleon BORLINI
ST Employee

I ​don't think the two sensors can influence each other from a 6-inches distance. The sw reset should help to decrease permanent magnetization. Are you seeing water condensation on the PCB at 5°C? Is it possible for you to "coat" the board and the exposed vias? Are the spikes on the graph related to the startup of the chamber cooling? Regards

MSend
Associate II

Well I figured it out. The data on my graph wasn't the RAW value of the axis as I thought, but an average of the last 20. I then also discovered i was running the ODR at 100 hz when my system would only be able to access it at about 60Hz. After lowering the ODR to 50hz and turning on the BDU function, the data errors disappeared. It appeared i was getting bad data somehow and it was shifting my readings by 255 points which caused the lower magnitude noise in my averaging values.

Thanks again for your help Eleon.