cancel
Showing results for 
Search instead for 
Did you mean: 

Use of VL53L1X

Doug_D
Associate

Hello - We are using VL53L1X to range a relatively short distance - from 0 to ~400mm.  We have a fixed target, which only moves in and out toward the sensor.  We want to know this target's position accurately, and update it frequently.  We have the sensor in the short distance mode, we calibrate a position, and we think we have a fundamental understanding of how the sensor is seeing the target.  All seems to work fairly well.  BUT, every so often, in an unpredictable way, without any external or environmental stimulus (that we can tell), it seems as the sensor reports a 'blip', whereby it reads a different value and then recovers to an original value.  This happens in less than 1-5 to 2 seconds.  There may be cases where it does not recover, but we can see an event we trigger on movement of the target, and then an inverse event.

We are letting the sensor range for DAYS or even WEEKS without stoping the ranging or reseting the sensor in any way.  Is this appropriate?  Is there a potential cause of above or expected behavior of the sensor we should know about in this type of application?

Any input/feedback would be appreciated!

Thanks

Doug

3 REPLIES 3
John E KVAM
ST Employee

Doug - do you get any data out of the sensor besides distance?

Do you report the RangeStatus, Signal strength, and ambient light for instance?

The only thing I can think of is you are reading the output at the same time the sensor is updating the next result.

Inside the sensor there is a ranging engine and an I2C interface. 

The range is taken, the data moved to the I2C through dual ported memory and the interrupt set. 

We then start the next range. 

The theory is that if you read the data from the I2C in a timely manner we are good. But if you read the result in a random fashion, you might read the memory while it's being updated. 

It's really all I can think of. 

I'd be interested if I could see the data before the 'glitch', the glitched data' and then the fixed data.

if you get a 'glitch', could you immediately read again? Did you get the same numbers? Or are they normal?

- john


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.

Hi John - thanks for the quick reply!  

We are putting some heavier debugging in the code, to make sure we full understand what we are seeing.  So, stay tuned and I'll get you more.  

Its interesting, because our application actually does some pretty heavy filtering.  We basically take 4-8 samples from the sensor to determine an average (over 400-800ms).  If that average is greater than a threshold, we make a decision.  The threshold is 12.7mm right now.  So, what is happening is we are seeing a value - say its 100mm.  The sensor sees that value for days or even weeks, and we correctly are taking no action.  The target is sitting still and the sensor sees it.  

Then, it takes 4 to 8 samples and the average has a delta greater than 12.7mm (so 112.7 or 187.3) without moving the target, so we trigger some business logic.  THEN, after another 4-8 samples, it comes back to the 100mm number and we essentially report an 'inverse event'.  So, its not like its even a single reading.  its like a bounce up and then back.

To share more about the environment, we are placing the sensor in a custom plastic bin on a shelf in a refrigerator.  The sensor looks out from the back of the bin toward the front of the fridge.  There is a plastic target that takes up >60% of the reduced (4x4) FOV of the sensor.  its dark in the fridge, except when its opened (lights come on).  We don't see a correlation between opening fridge door and this behavior.  I just wanted to share this detail in case it triggers a thought for you.  I will report back with more technical data when I get my hands on it.  

i think the data we get back from sensor is valid, and the timing budget and inter-measurement period are working well.

Doug, I know your work is ongoing and it may be tedious to report every detail in this forum. Just one detail that hasn't been mentioned: consider the possibility that your sensor might momentarily lose track of the distance to the target—the plastic piece you mentioned—and then start detecting another surface that is at a different distance but still within the sensor's field of view.

 

Keep in mind that the sensor is based on a processor that has a life of its own and, in marginal cases, it might stop reporting the distance to one object and start reporting another.