Short Range Issue with VL53L4CD

[JMart.27]

Hi,

I've been testing out the VL53L4CD and it's working really well so far, however I'm having a bit of an issue at one specific short range point. Everything works smoothly until I get to about 15 mm above the sensor, then the numbers jump up erratically, intermittently, and actually start to decrease the closer I get towards the 0 mm mark (when my hand completely covers the sensor). I've attached a screenshot of my serial monitor readings when my hand is hovering roughly 15mm above the sensor (with the values in my code constrained between min 200 kcps and max 10,000 kcps), and as you can see it jumps to 10,000 sporadically. Basically I just want a gradual increase and hit the max threshold (i.e. 10,000 or whatever I set it to) when my hand is physically touching the sensor.

I suspected this might have something to do with either the "sigma threshold" or the "signal threshold" described on page 9 of the PDF attached (section 3.3), because a default value of 15mm is mentioned there, however when I try to include either of those functions in my code and setting them to 0 it doesn't seem to make a difference. So maybe I'm way off base with that.

Is it possible these sensors aren't as reliable at very short distances? Or do I need to calibrate something else? Any help would be greatly appreciated, thanks!

[John E KVAM]

You are the second customer I've heard of that wants to use signal strength as a way to indicate proximity. I don't think we ever envisioned using the sensor like this. The distance was meant to be the primary output and the signal strength was provided as a secondary output simply because we had it.

When the signal strengths are low, we use all 256 SPADs to gather as many photon strikes as we can.

As the target gets closer we reduce the number of SPADs we use to keep the signal in the 20Million range.

But there is a limit to how many SPADS we turn off. (Clearly if we turned them all off in the face of a very strong signal, we would not get an answer.)

What you are seeing, I think, is this sensor deciding it needs the minimum and on the next range thinking the minimum +1. You can check this by extracting the number of SPADs from the sensor.

As your hand gets even closer, and the SPADs are already at the minimum, the signal_per_spad will go up.

I don't think using the signal strength as the primary output is going to make you happy in the long run. There is too much variation in targets. Your idea is only valid if the sensor is looking at one specific target - like a piston of some sort.

Create an output giving the distance, the signal_per_spad and the number of SPADs. Using those 3 pieces of information, you should be able to figure something out that will make you happy.

(Sorry about the use of the word 'we'. Upon re-reading this I realize I used it as we - the designers of the chip, and we - the chip itself. I think I also use it as we - ST in general. I have to work on that.)

• john

. There is too much variation in targets. Your idea is only valid if the sensor is looking at one specific target - like a piston of some sort.

Create an output giving the distance, the signal_per_spad and the number of SPADs. Using those 3 pieces of information, you should be able to figure something out that will make you happy.

(Sorry about the use of the word 'we'. Upon re-reading this I realize I used it as we - the designers of the chip, and we - the chip itself. I think I also use it as we - ST in general. I have to work on that.)

• john

[JMart.27]

Hi John,

Thank you for the detailed info (also the all-encompassing use of "we" as the designers + the chip itself seems to make sense in this context, so all good). Clearly, I was singling out the wrong value in this demo code (as you mentioned, I should have been focusing on "distance in mm" as opposed to "signal_per_spad_kcps"). The distance output is giving me what I want -- though I have to calibrate/offset it a bit because it hits ~20mm when my hand covers the sensor (as opposed to 0mm), but that's a quick fix in the code.

I'm relatively new to all this, so I think part of my issue is that I admittedly have a somewhat tenuous grasp on how exactly this sensor functions in relation to the previous sensor I was using. I was previously using a VCNL4010 IR proximity sensor, which worked quite well but had a slightly limited range for my taste (it maxed out at about 8 cm, ideally I'd like a little more headroom without sacrificing very close distances, maybe 0 cm - 15 cm, something like that, so I started testing out your sensors because they have a longer range and operate much better behind a coverglass).

With the VCNL I would simply run the demo code and output the read proximity values (ranging from 0 to ~ 65,000, they'd call them "counts" -- but I'm not sure technically what units they are) and would interpolate those numbers into a more or less linear scale of 0% - 100% to my liking, which worked nicely. Seems like I was trying to do the same thing with the VL53L4CD, incorrectly interpreting the "signal_per_spad_kcps" as the "raw" distance output. I'm realizing that you guys already did the interpolating for me in the "distance in mm" output.

Out of curiosity, how are you arriving at those millimeter values (under the hood, so to speak)? Also, hardware-wise, is the distance output based on an IR component, or something else? I realize I'm asking you to explain how the sensor works in its entirety, so no need to provide a lengthy answer, I'm just starting to hit a wall in understanding some of the specifics.

The main reason I'm asking is because I'm noticing that the millimeter values in the distance output are a little jittery (with a margin of error of 0-5 mm when sensing a stable, un-moving object), so I was wondering what units/source values that millimeter output is drawing from, and if that data might be able to provide more resolution from one millimeter to the next, if that makes sense. If I can work with a much larger range of values from, say, 100mm to 0mm, that would be appealing. In any case thanks again for all your help!