cancel
Showing results for 
Search instead for 
Did you mean: 

Strange behavior of the VL53L0CXV0DH sensor.

RPavl.2
Associate II

Strange behavior of the VL53L0CXV0DH sensor.

I get the correct data (distance to the obstacle), with a normal change in the position of the obstacle (zoom in / out), the data changes correctly and corresponds to the real distance.

If the obstacle is sharply removed from the "field of view" of the sensor, I get 0 (or very small, 0-25mm, values), although it is logical to get infinity. I can’t understand, is this the usual behavior of the sensor, then I will make a code check or is it some kind of problem with my sensor?

Before that, I used sensors soldered on the board and did not encounter such behavior. The described situation occurs on the board of my PCB ordered in jlcpcb, but once again I will pay attention, most of the data is correct! This baffles me.0693W00000Lwh1bQAB.png0693W00000Lwh1WQAR.png

18 REPLIES 18
John E KVAM
ST Employee

What you are seeing is a 'ghost image'. You are getting a distance you are not supposed to see.

There are some reasons for this.

1) The coverglass is not calibrated. Light from the sensor hits the cover glass and return immediately. These photons get averaged in with the ones that hit the target, and you get a reasonable answer.

But when you remove the target you are left with only the errant photons. And they return a value.

solution is to run the crosstalk calibration.

2) Something is still in your field of view. The sensor 'detects' objects within a code of 27 degrees. But the transmitted light does not fall off immediately. So if you have a reflective object just outside that FoV, it might return enough photons to give you a ghost target.

The solution is to set the minimum signal rate. This is generally 1.5 times the crosstalk you have and is configured when you do the crosstalk calibration. But you can change.

First thing to do is compare the signal strength to your real signal. Is it much, much less? You can use a number 1.5 times that as your lower limit.

-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 your reply.

I don't use a cover glass, it's a prototype, it sits on my desk and doesn't need protection from dust or dirt, that is why I am perplexed.

Your second version is better for my case.

I will run some tests and report the results.0693W00000Lwu5vQAB.jpg

John, if it doesn't make it difficult for you, give a link to the description of the calibration process, I think I did not fully understand the features of working with this sensor.

John E KVAM
ST Employee

calibration is best described partially in the datasheet and in the user manual (which is cleverly hidden in the API one downloads from the web page.

But a short synopsis. If you are constantly off by a couple of cm or less, you need to offset calibrate. Range a lot, at something around 14cm away, and average your results. The difference between your answer and the correct answer is your offset. (There is software to help do this.)

If you don't have a coverglass (and there is nothing near the field of view) you do NOT need crosstalk calibration. This calibration measures the number of photons hitting the glass and immediately returning.

One does it by finding some point where the measured distance is less than the actual distance by 10 or 20%. (This point depends on the reflectivity of your target and the quality of your glass.)

By knowing the right answer and the ranged answer the software can estimate the crosstalk.

Here is where I direct people...

https://community.st.com/s/article/Time-of-Flight-Cover-glass


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.

While everything was as a layout, I also thought that I didn't need calibration. I corrected the strange millisecond data tending to zero by simply putting the data in a circular buffer, comparing and ignoring atypical data. But as soon as I put the glass down, and the essence of the project is that the sensor should stand behind the glass and measure the distance, I immediately got something completely different from the truth. So I have one way - to deal with calibration.

Thanks for the answer!

While I'm reading the methodology, I don't understand everything. When calibrating crosstalk, I will get some averaged value, further, by means of VL53L0X_WrWord(Dev, VL53L0X_REG_CROSSTALK_COMPENSATION_PEAK_RATE_MBPS, data); I write it to the "sensor controller". Everything is clear with this. I will have to spend enough time to adapt the existing code to my hardware and I really don't want to waste this time. It is not at all obvious to me the further use of this data. Please tell me the behavior of the sensor after recording calibration data into it. Now I have a certain layer of glass that creates for me one stream of reflected photons and an obstacle that reflects another part of the photons. I.e., the current distance is the averaging of the data of one and the second stream. After receiving the correction data, will the sensor simply stop processing the photons received when reflected from the glass, or will it simply "pull up" the received data to the reference ones using the correction value? In the first case, I'm ready to figure it out because it will give me the desired result, in the second case, I'll just get a more accurate value that I don't need. I ask you to understand my doubts correctly, I do not see a mechanism that informs the sensor about the start of testing, so the sensor does not have a set of received data, then what does it compare the correction with? Maybe I'm mistaken, or rather, I want to believe it, but I can't understand the logic of crosstalk compensation.

John E KVAM
ST Employee

All the received photons are averaged together. But some come from the glass and some come from the target.

That VL53L0X_REG_CROSSTALK_COMPENSATION_PEAK_RATE_MBPS tells the sensor, how much to 'cheat'. Knowing how many photons come from the glass tells the algorithm, how to adjust the final answer.

10 zero distance photons and 90 from the target will average to about 10% short, but if the sensor knows there are 10 zero distance photons, it can add that 10% back in before giving the answer.

You don't need to translate the code. You can do it yourself. Range on a target that returns a distance that is 10 or 20% short. Take several measurements and average them. Then set VL53L0X_REG_CROSSTALK_COMPENSATION_PEAK_RATE_MBPS to something and range again. If you are still short, increase the value. if you are too long, reduce the value. Eventually you will get something that looks about right.

(But using the code is easier.)

There is also a minimum signal rate that should be set to about 1.5 times the PEAK_RATE. This will keep the sensor from detecting a false target (just due to the coverglass.)

Good luck.

  • john

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

I wrote a long message with a bunch of questions, my mistake was to blame and all the questions are not relevant. I can't delete the message, so I just had to edit it

Hi, John, now I definitely need your explanation. I use a sensor VL53L0, a 4mm glass is placed above the sensor, without an air gap. I receive data from the sensor, thank you very much for the hint "But using the code is easier". Now about the data. I measure the distance up to 25 cm, more the sensor does not see through the glass. Offset correction end crosstalk correction is performed and gives results, the signal is obtained clean, without "junk" data. Is there a way to increase the detection range beyond 25cm? Maybe there are some hints or I need to change the sensor? I be is grateful for your opinion!