VL53L1CB Low Ranging Performance and Flickering

[dlux]

Hi,

I designed a sensor array containing multiple VL53L1CB sensors. They are configured to scan a 3x3 grid inside its view with multizone scanning. That works great at small distances but suffer a distances above ~1,5m.

Experimentation shows that the sensor never yield reliable results (even with 16x16 zone, 550ms budget, completely dark room with covers down, target is a white wall which should cover the entire FoV) above 2m.

Another issue is the flickering of datapoints. The video shows the issue: VL53L1CB Flickering issue - YouTube

Points in green are valid ranging results (RangeStatus = 0), cyan means RangeStatus = 14 and black is RangeStatus = 7.

The issue is that ranging results cycle through "Not Present", "VL53L1_RANGESTATUS_WRAP_TARGET_FAIL" and "VL53L1_RANGESTATUS_RANGE_INVALID"

even though the RANGE_INVALID is not realy invalid. It is exactly where i think it should measure.

I hope that someone can help me with that issue.

Sincerely

Daniel

[John E KVAM]

I think what you are seeing is just the limits of the sensor. We claim 4M in ideal conditions with an 88% reflective target. And I think your wall is just under 88% reflective to mean the limits are about 3.7M.

In order to fight the "Radar Aliasing" problem, we range with different internal timings. So that the cause of your 7,4 cycle.

• The range status 7 is the wrap around. It means that there is a mismatch between the 2 consecutive ranges
• The range status 4 is the phase out of bounds, it means that the events are returned after a too long time

These can be treated as warnings that there is something wrong with the data, but you can choose to accept the range info it if you know something about your system that leads you to believe the distance might be right.

The ambient can be pretty low - if you are using LED lighting and are not near a window - as LED lights produce absolutely no 940nm light.

What I really don't like about your results is the first line:

1. Sensor: 7 ROI: 9 Ambient: [31744, 4294967295, 4294967295, 4294967295] EffectiveSpad: 16.4375 Range: [8191, 65535, 65535, 65535] Status: [255, 255, 255, 255]

There is no reason that I can think of that would cause the sensor to decide 16 SPADS was a good idea.

[dlux]

The different internal timings might be the issue then. Is it possible to get the used timing from for example the sequence number? Then i could join 2 measurements with different timings.

Thank you for the response.

I heard that you are releasing a new sensor (vl53l5) in the middle of the year. Is it possible to aquire some samples to test them against my current setup?

[John E KVAM]

To get samples of parts before they are released, you have to go through your ST sales or distribution. The launch date is supposed to be July 1, but we may have a bit of trouble with that date due to a non-ST part with a long lead time.

We should be close though.

Given that you are allocaing 500ms to each range, I think you would be better off taking several measurements and merging them together. If you took multiple measurements you could compare status results and ranges to establish which are legit and average them together. That might be a fairly robust strategy.