LIS2MDL: Is it possible to set different low and high interrupt threshold?

[ngrigoriadis]

Hello,
I am working on a project using the LIS2MDL magnetometer sensor to build a smart parking device that detects the presence of a car based on the x-axis readings exceeding an interrupt threshold.

Currently, I face an issue with setting high and low thresholds for the interrupt. For example, if I set the high threshold to +30 and the low threshold to -30, and the x-axis reading is around 1400 mG, the interrupt remains consistently high. This makes it difficult to reset and detect new threshold crossings.

Is it possible to dynamically adjust the thresholds based on the initial raw data reading from the x-axis? For instance, could I configure the device to read the raw x-axis value during initialization and then set the high threshold to x_axis_val + 100 and the low threshold to x_axis_val - 100?

I’d appreciate any guidance or suggestions.

[Federica Bossi]

Hi @ngrigoriadis ,

You can follow the steps reported in the AN5069

The hardware interrupt signal can be either pulsed or latched:
• Pulsed interrupt signal: it goes to active level when the magnetic data exceeds one of the two thresholds
and goes low when the magnetic data are between the two thresholds (positive or negative). This kind of
interrupt is selected by setting the IEL bit in the INT_CTRL_REG register to 0.
• Latched interrupt signal: it goes to active level when the data exceed one of the two thresholds but is reset
only once the source register is read and not when the magnetic data returns between the two thresholds.
This kind of interrupt is selected by setting the IEL bit in the INT_CTRL_REG register to 1.

[ngrigoriadis]

@Federica Bossi, actually, I solved the issue mentioned above with Hard Iron calibration. I am using a pulsed interrupt signal for interrupt control in my magnetometer, but I wasn't taking the hard iron calibration into account. Despite setting the interrupt thresholds, the raw readings were high enough to always exceed the threshold, which caused the interrupt to remain active.