cancel
Showing results for 
Search instead for 
Did you mean: 

VL53L1X Distance Sensor 50% failure rate (erratic measurements).

Aurelius
Associate II

Hi,

We have an issue with a production build of a VL53L1X based design. The VL53L1X is interfaced to a PIC18F micro, I have inherited the codebase and hardware. The initial production run was for 500 units, of these approx 260 passed our production tests and some have been working well in the field for some time.

The remaining 240 all exhibit an almost identical failure mode. Basically the readings will only 

 


1 - Uart Output (Legacy Code - Good Sensor)

 

VTOF=345mm  (5989) (0)
VTOF=346mm  (5978) (0)
VTOF=346mm  (6020) (0)
VTOF=344mm  (5949) (0)
VTOF=345mm  (6153) (0)
VTOF=346mm  (5979) (0)
VTOF=347mm  (6098) (0)
VTOF=345mm  (6147) (0)
VTOF=347mm  (6176) (0)
VTOF=346mm  (6166) (0)
Min: 344, Max: 347, Avg: 345.70, Std Dev: 0.95

 

 

 2 - Uart Output (Legacy Code - Bad Sensor)

 

VTOF=652mm  (33) (1)
VTOF=524mm  (48) (0)
VTOF=571mm  (38) (7)
VTOF=496mm  (25) (1)
VTOF=734mm  (23) (1)
VTOF=570mm  (14) (1)
VTOF=604mm  (30) (1)
VTOF=515mm  (19) (1)
VTOF=550mm  (3) (2)
VTOF=587mm  (11) (2)
Min: 496, Max: 734, Avg: 580.30, Std Dev: 70.73

 

 

*Numbers in brackets are "signal_rate" and "range_Status"

Above tests were run with a 300*200 grey target at 350mm, indoor lighting.

The inherited codebase was written some time ago by an outside contractor. I decided to implement the Ultra Lite Driver to see if the issue was to do with the firmware (the old code just puts a "known good" calibration table into the VL53L1X and begins reading).

After porting the library and writing some debug code, the bad sensors are still reading incorrectly. Although they are now much worse than when using the legacy code. I assume I will have to perform some calibration to get the offsets correct, but the repeatability issue remains on the bad sensor, which offest won't fix anyway.

 

3 - Ultra Lite Driver Register Printout (Good Sensor)

 

Timing Budget in ms           : 100
Distance Mode                 : 2
Intermeasurement Period in ms : null
Boot State                    : 3
Sensor ID                     : 60108
Measured Distance             : 673 mm
Signal Per SPAD               : 24 kcps
Ambient Per SPAD              : null
Signal Rate                   : 440 kcps
Number of SPADs               : 1
Ambient Rate                  : null
Range Status                  : 2
Result - Distance             : null
Offset                        : null
Crosstalk (Xtalk)             : null
Distance Threshold Window     : 0
Distance Threshold Low        : null
Distance Threshold High       : null
ROI Width                     : 63815, 4096
ROI Center                    : 199
Signal Threshold              : 1024 kcps
Sigma Threshold               : 90 mm

 

 

4 - Ultra Lite Driver (Bad Sensor)

 

Timing Budget in ms           : 100
Distance Mode                 : 2
Intermeasurement Period in ms : null
Boot State                    : 3
Sensor ID                     : 60108
Measured Distance             : 629 mm
Signal Per SPAD               : 25 kcps
Ambient Per SPAD              : null
Signal Rate                   : 464 kcps
Number of SPADs               : 1
Ambient Rate                  : null
Range Status                  : 2
Result - Distance             : null
Offset                        : null
Crosstalk (Xtalk)             : null
Distance Threshold Window     : 0
Distance Threshold Low        : null
Distance Threshold High       : null
ROI Width                     : 63815, 4096
ROI Center                    : 199
Signal Threshold              : 1024 kcps
Sigma Threshold               : 90 mm

 

 

 

On production units the sensor is protected by glass, with a 3d printed baffle to minimize cross-talk. I've validated that there's no effect from the hardware. The good/bad divide remains the same regardless of whether the glass or baffle is present. I've also validated supply rails are noise free and stable under operation. The "bad" sensors do not look dirty or damaged under the microscope.

 

I'll be implementing xtalk and offset calibration but I'd like to know if there are any other registers that I should be setting or adjusting? Or could it be that we have a bad batch of VL53L1X  sensors?

I'm also not sure why many of the registers are returning errors? (My debug function marks any that do not return "VL53L1X_ERROR = 0" as "null")

 

Thanks in advance for your help.

 

14 REPLIES 14
John E KVAM
ST Employee

WARNING - Do NOT view that light through any kind of magnification. When you concentrate laser light it becomes dangerous. You cannot see it and a concentrated Laser light will damage your eyes.

Now you have video evidence that you have very little output signal, and that the sensor is actually turned on and operating.

Now you have to figure out why the coverglass of the 'good' sensor is letting the light through and the coverglass of the 'bad' sensor is not. 

I have to believe that these cover glasses are not the same.

- john


Our community relies on fruitful exchanges and good quality content. You can thank and reward helpful and positive contributions by marking them as 'Accept as Solution'. When marking a solution, make sure it answers your original question or issue that you raised.

ST Employees that act as moderators have the right to accept the solution, judging by their expertise. This helps other community members identify useful discussions and refrain from raising the same question. If you notice any false behavior or abuse of the action, do not hesitate to 'Report Inappropriate Content'

With 1/10 of the signal coming back, you do get erratic values. But as all of your distances are short, you are getting an amazing contribution from your coverglass.

Just based on the fact that your bad measurements are long I'm guessing your coverglass is spreading the light far and wide, hitting the wall behind your target and bouncing back.

Take the glass off and look at it through a microscope. My guess it will look like creators of the moon. Or it's all scratched.

- john


Our community relies on fruitful exchanges and good quality content. You can thank and reward helpful and positive contributions by marking them as 'Accept as Solution'. When marking a solution, make sure it answers your original question or issue that you raised.

ST Employees that act as moderators have the right to accept the solution, judging by their expertise. This helps other community members identify useful discussions and refrain from raising the same question. If you notice any false behavior or abuse of the action, do not hesitate to 'Report Inappropriate Content'
Aurelius
Associate II

Hi John,

As mentioned before, I'm 1000% sure this issue has nothing to do with cover glass. We have hundreds of these units and enclosures (with cover glass), no matter how we pair them up... the bad sensors are always bad and the good sensors are always good.

These are fresh off the production line, and ~260 of them look to be faulty.

As I mentioned earlier : 

 

I really don't think this is a cover glass issue, I have already tried 2 samples from the "good" and "bad" batch with each of the following tests, with and without calibration.

- No baffle or glass.

- Baffle without glass

- Baffle with glass.

I also experimented with the distance mode and timing budget.

 

No matter what I do the result is the same, the "good" sensors remain working perfectly, the "bad" sensors remain erratic. 


 

To demonstrate this I removed the cover glasses and tested again with the microscope.

Bad sensor : 

Aurelius_0-1706287182809.jpeg

 

 

Good Sensor :

 

Aurelius_1-1706287198455.jpeg

 

There are things that will affect how bright the sensor appears such as angle and ambient light. I've kept those as constant as possible. No matter what way I look at it (literally) the bad sensors have little to no output compared to the good sensors.

 

So the possibilities are

(a) There are some registers I can adjust to set the laser output.

(b) We have faulty sensors.

(c) Some manufacturing defect (this is unlikely I feel, the boards look perfect and we use a very well regarded PCBA supplier).

 

John E KVAM
ST Employee

OK, you've convinced me.  Now you have to deal it whomever you bought them from to work out some sort RMA procedure. If they are broken, then ST will want to have a good look at them. Unfortunately, I have no idea how one does that. I've never gone through the process. But the process starts with your distributor. 

- john


Our community relies on fruitful exchanges and good quality content. You can thank and reward helpful and positive contributions by marking them as 'Accept as Solution'. When marking a solution, make sure it answers your original question or issue that you raised.

ST Employees that act as moderators have the right to accept the solution, judging by their expertise. This helps other community members identify useful discussions and refrain from raising the same question. If you notice any false behavior or abuse of the action, do not hesitate to 'Report Inappropriate Content'
Aurelius
Associate II

Thanks John,

That's not good news for us, but at least we know where we are.

 

I appreciate all the help.