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

[Dragos Ionescu]

Posted on June 12, 2017 at 15:32

But... it doesn't makes sense. The presence of equivalent magnetism produced by a fridge type magnet can happen everywhere, mobile phones are exposed, everything can be exposed. I understand that above 1000 G (as data-sheet is stating) bad things might happen but for such a normal, everyday values I did not expect to produce permanent problems.

[Dragos Ionescu]

Posted on June 12, 2017 at 20:30

Even worse, I'm not able to reset the readings this time, even by power cycling.

The readings before/after (in mGauss):

 psos_addr |      msg_datetime       | x1_mag | x2_mag | y1_mag | y2_mag | z1_mag | z2_mag

-----------+-------------------------+--------+--------+--------+--------+--------+--------+------------- 00000048  | 2017-06-12 01:12:26.875 |    277 |    235 |   -631 |   -647 |     275 |       64 |  00000048  | 2017-06-12 01:13:19.75   |    230 |    196 |   -642 |   -606 |      58 |      283 | 00000048  | 2017-06-12 02:33:14.687 |    383 |    359 |   -525 |   -420 |     482 |     500 | 00000048  | 2017-06-12 02:33:18.687 |    401 |      94 |   -423 |   -583 |     518 |     313 |  00000048  | 2017-06-12 03:28:17.687 |      84 |    317 |   -579 |   -495 |     317 |   4208 |

 00000048  | 2017-06-12 03:28:38.687 |    310 |  1045 |   -493 |   -118 |   4212 |   4266 |

 00000048  | 2017-06-12 03:29:26.687 |  1042 |    318 |   -122 |   -493 |   4271 |   4207 |  00000048  | 2017-06-12 03:30:16.687 |    318 |    282 |   -490 |   -510 |   4207 |   4162 |  00000048  | 2017-06-12 03:47:31.687 |    271 |    241 |   -503 |   -750 |   4164 |   4169 |  00000048  | 2017-06-12 04:20:05.187 |    249 |    214 |   -751 |   -748 |   4167 |   4160 |  00000048  | 2017-06-12 05:20:45        |    198 |    351 |   -753 |   -639 |   4163 |   4184 |  00000048  | 2017-06-12 05:48:17.687 |    347 |      80 |   -629 |   -609 |   4167 |   4148 |  00000048  | 2017-06-12 12:59:03.875 |     -13 |       4 |   -449 |   -531 |   4309 |    4255 |

[Khaled Aljehani]

Posted on September 26, 2017 at 10:26

Hi

Ionescu.Dragos

‌

Did you solve your problem?

[yeyoboe]

Hi Dragos Ionescu,

Did you managed to further investigate your problem? Im facing the exact same issue you described, when a strong magnet overflows the magnetic measurement, the magnetic reading won't come back to the expected value even if the magnet is not present near the sensor.

Would appreciate any suggestion from your experience. 

[Tesla DeLorean]

Might try LinkedIn this post is from SEVEN years ago, and several forum transitions. Respondents unlikely to be alerted or revisit.

[yeyoboe]

I managed to solve my particular problem. On my case the PCBs that presented the fault were assembled incorrectly and the external capacitor C1 100nF required by the LIS3MDL on pin4 were swapped for 10nF value which caused the fault. Fault: the measurement output was stuck at the maximum value after the magnetic range of the sensor was overflowed, even when no strong magnet was present.