LIS3MDL: unexpected readings

[Dragos Ionescu]

Posted on June 05, 2017 at 20:31

Hi,

We're using LIS3MDL to detect changes in the earth magnetic field due to various metallic objects flowing in the sensor proximity. So, we are not interested in the correctness of the absolute values in order to properly detect the magnitude of the field or the North direction, we only need to compare the magnitude of the field between consecutive measurements. That being said, I don't see any reason to calibrate the readings.

The problem we are facing is that for unknown reason, the readings (mostly on Z axis, but I've seen also for Y) on some of our sensors are sometimes evolve from initial 'right after boot & install', normal values to really unexpected and different values. The external conditions are the same, the magnetic field is the normal earth field.

Please have a look on this table, it's basically a log with recordings (x1, y1, z1 is the first measurement, x2, y2, z2 - second measurement, typically after two minutes):

Id                     Timestamp                              x1        x2          y1         y2          z1           z2

00000094 | 2017-05-18 02:32:08.625 | 0    | -53  | -89  | -173 | 496   | 438   | 000007d2

00000094 | 2017-05-18 02:34:16.625 | -60  | -41  | -162 | -160 | 456   | 504   | 000007d2 00000094 | 2017-05-18 02:36:39     | -84  | -15  | -177 | -85  | 448   | 519   | 000007d2 00000094 | 2017-05-18 02:36:55.625 | -14  | -4   | -90  | -114 | 538   | 508   | 000007d2 00000094 | 2017-05-18 02:37:51.625 | -6   | 15   | -112 | -114 | 502   | 530   | 000007d2 00000094 | 2017-05-18 03:04:49.75  | 10   | -27  | -111 | -198 | 486   | 432   | 000007d2 00000094 | 2017-05-18 03:13:48.75  | -49  | -31  | -205 | -212 | 471   | 509   | 000007d2 00000094 | 2017-05-18 03:18:19.75  | -40  | 0    | -206 | -134 | 462   | 544   | 000007d2 00000094 | 2017-05-18 03:18:58.687 | -2   | 52   | -136 | -187 | 544   | 425   | 000007d2 00000094 | 2017-05-18 03:24:35.687 | 101  | 75   | -169 | -156 | 452   | 397   | 000007d2 00000094 | 2017-05-18 03:37:30.187 | 58   | -43  | -120 | -160 | 395   | 437   | 000007d2 00000094 | 2017-05-18 04:09:08.812 | -69  | -4   | -197 | -112 | 471   | 552   | 000007d2 00000094 | 2017-05-18 04:10:04.75  | -6   | 18   | -112 | -119 | 538   | 486   | 000007d2 00000094 | 2017-05-18 04:22:32.75  | 1    | 19   | -132 | -130 | 521   | 562   | 000007d2 00000094 | 2017-05-18 04:38:05.687 | 11   | 26   | -88  | -87  | 474   | 508   | 000007d2 00000094 | 2017-05-18 04:49:14.562 | 64   | 131  | -63  | 88   | 511   | 243   | 000007d2 00000094 | 2017-05-18 04:53:23.562 | 131  | 151  | 102  | 103  | 235   | 282   | 000007d2 00000094 | 2017-05-18 05:15:09.187 | 112  | -670 | 115  | 739  | 193   | -2581 | 000007d2 00000094 | 2017-05-18 05:17:39.187 | -675 | -692 | 757  | 821  | -2587 | -2698 | 000007d2 00000094 | 2017-05-18 05:33:11.187 | -671 | -546 | 713  | 868  | -2369 | -2268 | 000007d2 00000094 | 2017-05-18 05:33:57.687 | -547 | -546 | 869  | 916  | -2286 | -2309 | 000007d2 00000094 | 2017-05-18 05:42:30.187 | -555 | -560 | 910  | 864  | -2299 | -2261 | 000007d2 00000094 | 2017-05-18 05:43:49.187 | -559 | -555 | 871  | 906  | -2262 | -2302 | 000007d2 00000094 | 2017-05-18 05:50:51.187 | -533 | -545 | 874  | 826  | -2307 | -2270 | 000007d2

...

00000094 | 2017-05-23 07:48:58.187 | -486 | -414 | 539   | 534   | -1976 | -2196 | 000007d2

00000094 | 2017-05-23 07:49:38.187 | -415 | -489 | 539   | 544   | -2185 | -1990 | 000007d2 00000094 | 2017-05-23 08:09:22.687 | -491 | -524 | 540   | 418   | -1994 | -2097 | 000007d2 00000094 | 2017-05-23 08:24:54.375 | -532 | -501 | 399   | 523   | -2075 | -1946 | 000007d2

...

00000094 | 2017-05-28 10:57:12.562 | 126  | -52  | -4770 | -4770 | -4788 | -4752 | 000007d2 00000094 | 2017-05-28 10:57:13.062 | -56  | 352  | -4770 | -4770 | -4752 | -4788 | 000007d2 00000094 | 2017-05-28 11:47:07.5   | 342  | -156 | -4770 | -4770 | -4788 | -4752 | 000007d2 00000094 | 2017-05-28 12:05:15.562 | -134 | -344 | -4770 | -4770 | -4752 | -4753 | 000007d2 00000094 | 2017-05-29 01:27:41.312 | -325 | -181 | -4770 | -4770 | -4753 | -4752 | 000007d2 00000094 | 2017-05-29 01:34:39.062 | -194 | -336 | -4770 | -4770 | -4752 | -4753 | 000007d2 00000094 | 2017-05-29 01:45:55.062 | -313 | -384 | -4770 | -4770 | -4753 | -4753 | 000007d2

In bold with red are rows where things went wrong in my opinion, values shifted significantly without any external influence since the sensors where in a controlled area, on ground.

Basically we are stuck here, I can't imagine what could trigger such a shift in the values.

Some other facts that might help:

1. The sensors are potted in a resin which is certified for electronics encapsulation.

2. Temperature variations are likely to occur, first during the potting process (max. 60 C), next due to exposure to the sun light (again, max 60 C by estimation)

3. We brought the sensor from we've taken the log from the field in the lab and we did a reset on the battery. We were surprised to see that the values came to normal, right after reset!

3. We performed some tests with sensors without encapsulation and the shift did NOT occurred. Those tests happened about one year ago.

4. Batteries. We are using Lithium SoCl2 batteries which are quite old and they passivate but we have managed to brought them alive. Theoretically it could happen to have some voltage drops from time to time... but we also have a radio transmitter on sensor which works well with no sign of interruption due to a voltage drop.

5. Some sensors (in fact more than a half) does not visibly manifest the issue but we are suspecting that the issue is still present in small amounts. 

It seems that the encapsulation somehow triggers the issue but we don't know what could be the real reason. So far we've tested the temperature variation in lab, the sensors behavior is normal - a small drift which is acceptable in our case.

Does anyone have an idea what could be wrong? We are not able to reproduce the behavior in a controlled environment.

Thanks,

Dragos

#lis3mdl

[Miroslav BATEK]

Posted on June 06, 2017 at 09:55

From your facts 3 and 4 I would suspect the short voltage drop which can cause this issue.

LIS3MDL generates high current pulses on Vdd which needs to be covered by blocking capacitors and power supply. 

[Miroslav BATEK]

Posted on June 06, 2017 at 11:41

I don't have any experience with this kind of issue, but I can imagine the principle of this failure. The sensor loads calibration constants during start-up to volatile memory, I think, the voltage drop can cause that the data are corrupted in the memory and the the output values are wrong. When you restart the sensor it loads the calibration constants again and works well then.

There is possibility to do reboot of memory content, writing ''1'' to REBOOT bit in CTRL_REG2.

Maybe one more idea. If the ambient temperature is high, the capacity of blocking capacitors can be reduced and the they didn't cover the current peaks well.

Did you check performance of the blocking capacitors at high temperature?

[Dragos Ionescu]

Posted on June 06, 2017 at 11:03

Hi, we've also suspected this problem and we will do some tests with new batteries these days. Still I have some doubts cause we use the LIS3MDL in low power mode, taking 4 samples per second. The voltage drop looks very little on the oscilloscope on a regular basis but of course it could go wrong randomly. A voltage drop would also have caused a restart of the processor which didn't happen.

One thing would add more clarity: the sensor indicating wrong values (see table, rows after

2017-05-28 10:57:12.562

moment) permanently, behaved normally after a restart. Is this a known behavior of LIS3MDL? Meaning that a voltage drop could cause a permanent failure in the sensor readings, even if the voltage comes back to normal values afterwards? Can we do a soft reset to correct the issue?

Thanks,

Dragos

[Dragos Ionescu]

Posted on June 06, 2017 at 12:24

Thanks Miroslav, the scenario you have mentioned is the one I was thinking about, somehow the internal registers of the chip are corrupted and the reset cleans it up.

We have followed the data-sheet recommendations regarding the capacitors:

The LIS3MDL requires one external capacitor (C1 = 100 nF) connected between pin 4 and GND. The device core power supply line (Vdd) needs one high-frequency decoupling capacitor (C3 = 100 nF, ceramic) as near as possible to the supply pin, and a low-frequency electrolytic capacitor (C2 = 1 μF)

The only difference is that, due to space restrictions we have used a ceramic 1uF/25V capacitor for low freq decoupling instead of the electrolytic type. All caps are rated at least -55C +85C.

The are no more capacitors on the board, the battery should normally be able to provide enough current as per specs it can supply at least 50mA in continuous mode.

[Miroslav BATEK]

Posted on June 06, 2017 at 13:14

Ceramic capacitor is OK. You probably know it, but I should mention that there are different materials of the capacitors. You can check this

https://en.wikipedia.org/wiki/Ceramic_capacitor

page.

If you use for example Y5V material the capacity can drop up to -82% with temperature and you mentioned the temperature in your device can be quite high due to sun light. And if it is the only one capacitor on the board you can have a trouble. Usually X7R or NPO materials are good to use.

[Dragos Ionescu]

Posted on June 06, 2017 at 13:31

It's X5R...

http://ro.mouser.com/Search/ProductDetail.aspx?R=GRM155R61E105KA12Jvirtualkey64800000virtualkey81-GRM155R61E105KA2J

actually. It could be better... for a 603 case. I can fit a few for tests but the problem is that I cannot reproduce the issue in the lab, we're still trying.

[Nick1]

Posted on June 08, 2017 at 16:19

One possibility is that the ceramic capacitor is cracking due to the combination of potting and temperature changes.  The thermal expansion of the epoxy may be stressing the capacitor and cracking it.  The crack might cause a brown-out that resets the memory. Changing the temperature would then lead to intermittent behavior as the capacitors layers shift. Have you checked the current consumption of the device before/during/after?  If you see significant changes it would be an indication that the ceramic capacitor is damaged.

[Dragos Ionescu]

Posted on June 12, 2017 at 12:25

Hi, I have some news here. So, we managed to replicate the issue by applying a strong magnetic field to the sensor, let me first explain. In our application we need a kind of magnetic switch to trigger an event different than a normal magnetic detection. This switch is implemented by reading the magnetic values from the sensor when is 'saturated' (the magnetic values are at their maximum values). In practice, in order to generate that strong magnetic field we are using a simple magnet (not neodymium) - decorative fridge type and, for one second or two, we place the magnet nearby the sensor.

The sensor is using the +-4gauss sensitivity (highest).

It seems that, sometimes, when the sensor is put temporary in a high magnetic field it affects the following measurements, somehow the internals register values are shifted in an irreversible way (till reset).

By reading the documentation I see some hints:

DF Magnetic disturbance field Zero-gauss offset starts to degrade: 50 gauss

MEF Maximum exposed field: 1000 gauss

The IC interface is factory calibrated for sensitivity (So) and Zero-gauss level (TyOff). The trimming values are stored in the device in non-volatile memory. Each time the device is turned on, the trimming parameters are downloaded to the registers to be employed during active operation which allows using the device without further calibration.

From wikipedia:

10−3millitesla

5 mT

50 G

The strength of a typical

https://en.wikipedia.org/wiki/Refrigerator_magnet

https://en.wikipedia.org/wiki/Orders_of_magnitude_%28magnetic_field%29#cite_note-6

So, a refrigerator magnet can degrade the zero-gauss offset and this is permanent until a reset I suppose. Can we do this reset in software by calling REBOOT?

Is this a safe procedure, meaning that every time a saturation happen we should reboot the sensor?

Thanks

[Miroslav BATEK]

Posted on June 12, 2017 at 15:07

I don't have any experience with this kind of application, but I discuss it with my colleague and he would not recommend to use the sensor for this kind of application. Strong magnetic field can significantly degrade the sensor performance. He also told me that SW reboot will probably not help, only power cycling should solve the sensor freeze, of course you can try the SW reboot in your particular case.