cancel
Showing results for 
Search instead for 
Did you mean: 

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

EVuša.1
Associate II

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.

11 REPLIES 11
John E KVAM
ST Employee

​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?


If this or any post solves your issue, please mark them as 'Accept as Solution' It really helps. And if you notice anything wrong do not hesitate to 'Report Inappropriate Content'. Someone will review it.
EVuša.1
Associate II

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
ST Employee

​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.


If this or any post solves your issue, please mark them as 'Accept as Solution' It really helps. And if you notice anything wrong do not hesitate to 'Report Inappropriate Content'. Someone will review it.
EVuša.1
Associate II

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
ST Employee

​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.)


If this or any post solves your issue, please mark them as 'Accept as Solution' It really helps. And if you notice anything wrong do not hesitate to 'Report Inappropriate Content'. Someone will review it.
EVuša.1
Associate II

Both interrupts happen after TimingBudet has passed after calling startMeasurement

John E KVAM
ST Employee

​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.


If this or any post solves your issue, please mark them as 'Accept as Solution' It really helps. And if you notice anything wrong do not hesitate to 'Report Inappropriate Content'. Someone will review it.
EVuša.1
Associate II

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
Associate II

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.