VL53L4CD - occasional spurrious in-range results when there's no target

[pretoriandave]

Hi All,

I'm developing a proximity switch using VL53L4CD

My unit works perfectly 99.9% of the time but I’m seeing occasional instances where the unit triggers very briefly even when there’s nothing in range. It may go an hour between such events, even several hours, but equally it can on rare occasions do it twice in a minute. It’s almost like a fly flew through the beam. It’s literally on in one frame and off again in the next.

I’m using the UL driver without thresholds (RS_IT_DEFAULT), since I need to enforce some hysteresis. My ranging frequency is 20Hz. The unit has the standard cover glass and I’m calibrating it before use with a 17% target. I get the problem whether or not the cover glass is fitted, and the amount of ambient light doesn’t seem to be a factor.

I only allow a change of state to ‘on’ when ToF status = 0 and distance <= threshold, so that must be happening occasionally even when there’s no target.

This is a production ready pcb but in an effort to see what was happening I lashed an ST-Link into the circuit so I could set a breakpoint and see what’s going on. Here’s the weird bit – it never happens when running the code that way (although because it happens so infrequently it’s difficult to be sure of anything). The only way I see this problem is when the unit is completely stand-alone, which denies me any debugging capability.

So my question is whether it’s possible for the device to report status =0 and a plausible distance even when there’s no target? If so, is there any way to address it or do I need to think about adding debounce? I was trying to avoid debounce because it will introduce lag.

I’m aware that the device is essentially running a statistical model so maybe there are extreme occasions where it gets it wrong.

Many thanks for any advice.

[John_Kvam]

In the 8 years I've supported the VL53 sensors, this is the first i've heard of such and issue. 

But let us assume it happens. I'd bet that when a 'fake' target shows up it has a very small signal strength. 

Increasing the signal strength from it's default (which I think is 0.5MegaCountsPerSecond) to something like 0.75MCPS should eliminate the issue. A good signal rate should be many MCPS, so there should be some wiggle room.

If it doesn't eliminate the issue find some way to record what the signal strength is and set the lower limit to something just over that. 

- john

[John_Kvam]

I had another thought. If you under compensated for the crosstalk, a ghost image might appear. The photons reflecting from the coverglass are mis-interpreted as returning reflection from a target. An easy way to tell is get the coverglass a little dirty and see if the problem gets worse. A big old finger print should do it, or a bit of hand cream or perhaps a bit of scotch tape. 

Penalty for under calibrating is a ghost image and slight over-ranging. The penalty for over compensating is that near targets will be a few percent under ranged. 

But anything is better than a ghost image. 

But if it were a ghost image, increasing the minimum signal will also solve it as the crosstalk photons do not return a very strong signal. 

- john

[pretoriandave]

Hi John, and sincere thanks for keeping up with the community even after you've retired. Definitely above and beyond, but is certainly appreciated by me and I'm sure many others too.

This one is driving me crazy. On Friday it happened three times in 15 minutes and on the fourth occasion I was able to do it with ST-Link connected so I finally got a set of readings: Distance =6mm, Status =0, ambient = +6 and signal = +4. So just as you said, a small signal. It didn't do it again after that.

After that I monitored it all weekend and it didn't do it once. Now, given your second post I wonder if the cover glass was a bit dirty and maybe that's what led to the spurrious events, I can't be sure.

At present my firmware is set up to do end-of-line calibration but not crosstalk compensation. The reason I didn't think it necessary to do the latter is that I'm not seeing a point of inflexion in my transfer curve and therefore didn't think it was necessary. Maybe that's flawed thinking. Besides, crosstalk compensation looks rather cumbersome on a production line so I was hoping to avoid it. That said, I am going to re-record the curve today to check it's still linear.

My maximum range is 500mm, so any point in inflexion there may be is likely well beyond that. Again, I thought it unnecessary on that basis, but that may be an incorrect viewpoint.

I did try intentionally making the cover glass dirty as you suggested and sure enough if I make it VERY dirty, it will chatter away, but with day to day finger marks on it, it doesn't seem to be affected, although it happens so infrequently, it's hard to be sure of anything.

Is it your view that I should definitely do crosstalk compensation? Obviously increasing the threshold per your first post is very much easier (it's currently set to the default of 1MCPS so I would need to increase it quite a lot, if as I assume the UL driver is giving me signal strength also in MCPS. A reading of +4 would suggest I may need to go up to 8 MCPS).

Many thanks once again