Strange behavior of the VL53L0CXV0DH sensor.

[RPavl.2]

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.

[John E KVAM]

A 4mm glass is extremely thick. And is the root cause of your issues. You have accounted for the crosstalk, but since so many photons are reflecting off that glass, you don't have enough left over to do what you want.

You can prove this by putting that glass down on the Evaluation kit and trying it. As we know our code works, it will give you the best performance you can get. But I'm thinking you will be unsatisfied.

The only solutions I can think of is to thin the glass, or switch sensors.

Both the VL53L3CB and the VL53L4CX, will fit perfectly. but they are more expensive.

They use a different bit of code that is immune to crosstalk over 80cm. and as this logic is more sensitive, I'm thinking they will work for you.

If you have fifty dollars, buy the X-NUCLEO-53L3A1 or the X-NUCLEO-53L4A2 and test them on the Nucleo F401RE you already have for your VL53L0X Eval kit. Proving it works before you get very far is the key.

• john

[RPavl.2]

John, I received confirmation of my assumptions, it was important for me to understand that I had done everything possible. Thank you for that! I will definitely buy X-NUCLEO-53L3A1 for tests, it seems to me very promising.

[RPavl.2]

John, I received confirmation of my assumptions, it was important for me to understand that I had done everything possible. Thank you for that! I will definitely buy X-NUCLEO-53L3A1 for tests, it seems to me very promising.

[RPavl.2]

John, I have a new problem. Tell me, is there a way to limit the size of the visible object? I use the sensor for level measurement and it works fine, but i also need the sensor not to react to vapor particles, this is especially important when a large object is out of the sensor's field of view. If there are small particles (vapours) in the air, the sensor sees them and measures the distance to them, but if you place your hand in the sensor's field of view, the sensor measures the distance to the hand quite accurately, i.e. the number of particles reflected from the hand is larger and for the sensor this is "reference" information, but how can one exclude the measurement of the distance to small vapor particles suspended in the air? The vapor is dense enough but not hot, nothing threatens the sensor😀

[John E KVAM]

There are two important measures the sensor returns - Distane of course, but you need to look at signal strength.

A nice solid object is going to return a nice, high single rant - where vapor might get enough signal to return an answer - but the signal rate willl be much lower.

Getting the true signal rate is a bit of a trick however. We have an array of 16x16 SPADs that detect the photons, but if we are getting tons of photons, we turn a lot of those off.

So you neeed to get read the signal rate AND the number of SPADs. Calculate the Signal per SPAD (although I generally normallize it by multiplying it by 200 ( the effective max spad count.)

Signal = (signal_rate / number of spads) *200

Big signal means you have a good target, small signal means you have water vapor.

But where you set the boundry is up to you experiment.

There is also a Sigma value. This is the standard deviation of all the photon timings. I'm very sure that a real target will have a standard deviation that is MUCH less than that of Vapor.

You've been working on this for a long time. Write me an email at john.kvam@st.com and tell me who you are, where you live and give me some idea of what you are building if you can.

• john

[RPavl.2]

The task didn't seem difficult, but i have a problem. Application note - AN 5191 describes in detail access to the values of the SPAD array for vl53L1, but for vl53l0 I can't find something similar. Please tell me where I can read about it?

[RPavl.2]

The task didn't seem difficult, but i have a problem. Application note - AN 5191 describes in detail access to the values of the SPAD array for vl53L1, but for vl53l0 I can't find something similar. Please tell me where I can read about it?

[John E KVAM]

The VL53L1X has a lens over the receiver SPAD array. So we can tell from where in the field of view the photons came from. The L0, L3 and the L4 have no such lens. So all we know is that a photon struck the SPAD and we counted it.

So the documention on the L0, L3, and L4 is sparce becasue there is nothing you can learn from it.

The one thing you do have is the ability to know how many SPADs were used. If a target is close are very reflective, we will disable some SPADs to limit the power needed to reset them.

Thus to get the true measure of the situation you really should divide the return signal by the number of SPADs and multiply that by 200 to normalize it.

• john

[RPavl.2]

Thanks! It works great! I get the data, but I doubt that I did everything right, here is my solution realSignalLevel = vl53l0.SignalRateRtnMegaCps / vl53l0.EffectiveSpadRtnCount

I get data in the range from ~2000 (maximum), to 0(5-10 in the presence of vapor). I am quite happy with this, but it seems that I did something wrong as you wrote.