VL6180X wrap-around filtering: is this possible without the API?

[RichardR]

Hello,

I'm working on a project with a VL6180X ranging sensor, and I'm running into the problem that it responds to reflective surfaces far beyond the desired range (100 mm) - e.g. it picks up reflective stripes on the jackets of emergency personnel at over 1200 mm (4 feet) distance, rendering the whole thing unusable.

The datasheet mentions a Wrap-Around Filter (WAF) to solve this problem; however, it turns out that this filter (and only this filter) requires the use of the VL6180X API - which is a problem, as I'm using a simple PIC controller for the overall functionality (switching on a small liquid pump when a hand is within range).

I already checked out the API, but it isn't clear at all how this WAF works. Could someone shed some light on this? If it is merely a matter of setting a bunch of registers, my controller should be able to handle that just fine; and even if some continuous external processing is required, it shouldn't be impossible.

(I also looked if I could simply decrease the VCSEL output to limit the range, but there seems to be no register setting for this.)

What I don't want, is to redesign and rebuild the hardware and software in order to be able to use just this one feature.

Thanks already for any help!

Richard

[John E KVAM]

From the hardware guys,

"Just to eliminate the i2c interface, could he try both 100khz and 400khz. Lastly, can he check the voltage at the chip and system? 

It seems to me that this issue could be power related. He does have two sensors, and maybe with this highly reflective surface, all the spads are firing. (A triggering SPAD requires very little power, but quenching it - getting it ready for the next photon - takes a bit of power. So there is a slight bit more instantaous power draw with a bright surface. However, with a bright surface, one needs to range for a shorter time to get enough photons, so the power draw averages out.)

"If it is a power supply issue, he could try connecting a bench supply to his board and see if the issue still occurs. 

"I think eeither i2c or power supply would be the first two things to look at. Since it is reflectance related, i would guess the power supply first. "

[John E KVAM]

Another contact states he has seen a similar problem. System only failed in the white version of the product. Customer never found a solution. They chose to reset the sensor regularly. Bummer.

[RichardR]

Hello John,

Thank you for all the extra information, and in a way it is good to know that others have experienced some trouble with bright environments as well. We'll think about implementing a reset option.

The sensors have a dedicated 2.8V LDO power supply with generous local decoupling using several different ceramic capacitors. The I2C runs at a leisurely 100 kHz, albeit over several inches of flatcable, which may pick up occasional EMC.

About resetting the device: all controller pins are in use already, but I can implement a simple reset circuit using SCL with a high-impedance RC circuit and a Schmitt-Trigger buffer, to generate a low reset on GPIO0 if SCL is forced low for e.g. 100 ms (as SCL is high 99.9% of the time during normal operation).

As I already mentioned, the latest tests are encouraging in that we haven't experienced any problems lately. Testing & close monitoring continues in the next few weeks, and if we still get no spurious readings, I think we can safely put the system in production -- maybe with the extra reset circuitry, to be on the safe side.

Thanks once again, best regards,

Richard