VL53L1X - Interrupt(s) happening immediately after startMeasurement is called

[EVuša.1]

In my setup I have VL531LX proximity sesor connected as per datasheet.

Every time when I call startMeasurement interrupt is risen immediately after (often two interrupts).

By user manual UM2356, figure 3. this clearly should not happen.

I was wondering do you have any idea why is this happening. Thanks in advance.

[John E KVAM]

​The VL53L1X is designed to give an interrupt when the range is complete.

So if you are getting an interrupt immediately perhaps you have the polarity of the interrupt backwards.

The default is active low.

Manual says "By default, GPIO1 is pulled down when a new ranging data is ready."

There is a software API call to reverse this. I'd say play with that and see if you like it better, but you might be fighting your pull-ups.

Could that be it?

[EVuša.1]

Thanks for answer.

I assumed active low. I have GPIO1 pulled up by 10k resistor to 2.8V. Also interrupt is triggered on falling edge. From what I can tell VL53L1X is set to be in 2V8 mode in API by #define line. So I don't think that reversed polarity could be an issue.

Maybe I'm missing something?

[John E KVAM]

​Does it work if you ignore the first interrupt?

That #define line only tells the I2C interface where the half way point is when deciding the clock line is falling.

Does not affect the interrupt in any way.

[EVuša.1]

Well... Kinda.

​If I ignore those one or two noise interrupts rest of measurements are perfectly normal.

But problem is that I only want one actual interrupt, after which I'm stopping the measurement to change settings (which may not make perfect sense now but I have to do it). And it's not always one interrupt or always two interrupts, so there not easy to ignore.

[John E KVAM]

​I'm sorry, I don't have immediate solution.

One idea is to use the timing budget. After starting the device, you cannot get a 'real' interrupt until TimingBudget milliseconds have gone by.

So ignore them until at least that many milliseconds have gone by.

(I don't really like it as a solution, but until I really look into it, it's all I have.)

[EVuša.1]

Both interrupts happen after TimingBudet has passed after calling startMeasurement

[John E KVAM]

​I'm confused.

You say 'go' with the startMeasurement, and after TimingBudget number of milliseconds, you get an interrupt. That interrupt essentially says, "I'm done, you may read the result." That's how it's supposed to work.

Unless you set a threshold saying you want an interrupt only after the target is detected within the parameters of your threshold you are going to get an interrupt after every measurement.

Clearly I'm missing something here.

[EVuša.1]

Oh yes, you are right, I forgot to mention that I have threshold set. Also in detection config IntrNoTarget is set to 0. Interrupt should only happen when something is in front of sensor and is near enough. Those first interrupts happen before something is in front of sensor. So I call startMeasurement, get two interrupts, than nothing, than I place my hand in front of it and normal expected interrupts start going off. Sorry for not making problem clear enough.

[EVuša.1]

Okay, I did some digging.

From what I found out those first one or two interrupts are normal measurements. They are not noise. Their cause is sensor purposefully pulling pin down.

But problem is that those measurements ignore thresholds and checks set before startMeasurement. So it ignores signal rate check, sigma check and threshold values. I'm cannot claim that I'm 100% sure in this, but I'm pretty sure. After those 'wrong' measurements, checks are established and sensor works normally. Hope this helps.