Greetings!
I am using the LIS2MDL magnetometer in continuous mode (10 Hz) with hard-iron offset and interrupts enabled. (Full settings: CFG_A: 0x90; B: 0x0A; C: 0x50; INT_C: 0xE5) And I am trying to detect a magnetic object coming near the device. The interrupt threshold I have currently set is 80 (int). The sensor is powered with a stable 1v8.
When I leave the sensor to measure and wait for an interrupt in an environment with no stimuli, the sensors that I have at hand all seem to generate weird false impulses out of thin air. They appear in the form of bit/byte flips, that happen only on the MSB part of the 16-bit data block.
For example, if I am constantly reading the sensor values (at 10 Hz, same as sensor), there is a possibility that I will read the false vector value from the axis registers. The raw values for the X axis would look like: "0x0028; 0x0027; 0xFF28; 0x0029". As far as I have observed, this has only happened on the X axis (for the ~50 recorded instances, only one has been in the Z axis), and sometimes it's not only the whole most significant byte, but only the lesser bit of the MSB byte: "0x0027; 0x0128; 0x0028".
The outside environment noise is very miniscule and reaches only about 10% of the interrupt threshold. The values of the read vectors seem to be precisely either bit-flips or byte-flips, no natural values whatsoever.
Below is an image of the visualized output data with the sensor being in a stable environment, where the one reading above the pulsed has the byte-flip recorded on the X-axis.
Here we can see that the previous normal value in hex would be 0xFFAE and then the impacted reading is with a value of 0x00A7 (AE and A7 are within error), so a complete byte flip has happened, and not even "zeros to ones", but "ones to zeros". Note that there have been plenty other situations as previously described where 00->FF, this is an example of the opposite effect, since the record state was with a negative vector value, but with a positive vector value the bit/byte flip would make zeros to ones.
I have observed that the false impulses and their values are shorter than the time it takes to make another measurement, so instead of the false measurement being there for 100ms, it's there for about 50ms +/-30ms, so, if I don't read twice every measurement, there is a chance the false vector value will not be recorded and I only record the false impulse with no false value attached to it. The false impulse still happens on the interrupt pin, so it is not falsely read data with I2C or some form of data storage error. Adding a capacitor to the INT line lowered the amount of false impulses, but did not solve the problem completely.
I would like to know if someone has encountered a similar problem and knows what I may be doing wrong, since the current system I am making with this sensor requires there to be almost no false impulses, so I need to fix these false impulses.
Thank you for reading this and I am eager to get to the bottom of this.
Best regards
Mark
Hi, thank you for the reply!
I have just ran a test where i disable the interrupts on the sensor, while still listening to incoming impulses, but no impulses were detected.
I did, however, still read the bit/byte flips occasionally, so the problem seems to be hiding somewhere inside still.
I also noticed that I had previously set up the Vdd_io pin to be pulled to ground when the I2C interface was not being used, but after some contemplation it was wired to be permanently pulled to Vdd, in which the most recent test was performed in.
So the pin configuration is per datasheet spec with supply voltages voltages 1v8 for 4 sensors and 2v2 for another 2, but all tested sensors experienced the bit/byte flips. Below is a screenshot from the vector outputs in their value form:
The vector values are displayed in deciGauss; normal value ~-5.65
On two sensors I even turned off LP mode and enabled the low-pass filter, but one of them still experienced the bit-flip over night.
I will now test three evaluation boards with SPI to see if they produce the same unexpected behaviour as the other sensors i have.
I there are any other ideas on what to test, I can give it a spin.
Greetings again, @Federica Bossi ,
It has come to my attention that the hard-iron offset may be causing these bit/byte flips.
I ran a test where I left two pairs of sensors running for 5 days (~120h), where one pair has the HIO turned off and two have it turned on, but the offset is written only once during startup. And the results were interesting.
The pair with HIO turned on and the offset values having written only once during boot:
(the pink axis has a spike at ~6am on the 24th; the red axis has a spike at ~6am on the 27th)
The pair with the HIO turned off:
(no spikes on the axis)
There are two visible spikes in the HIO-on pair, where the calculated values were in fact a byte flip. Note that I am reading the vector values only every minute, so there could be a lot more of these glitches happening.
If this phenomena can be explained, I would love to hear it, otherwise, I shall be switching the sensor for another that is more stable.
