Weird Range reading delay with VL53L1X

[PChat.1]

Hello,

I am looking to scan a 2D surface with the ROI feature of the VL53L1X. I have been following the doc UM2555 and using the Polulu ST API but I can't get it working properly. The wall is at 1.6m and the object at 48 cm. The precision is not the issue, my problem is that the value returned by the function getMeasurement is 2 "range measure" late.

Could you help me find out why?

Thanks a lot for your help

[John E KVAM]

​are you sure it's two ranges late? When changing ROI's one writes the next  ROI center, while the current one is ranging. This way when the current range finishes the next one will grab the new center and start ranges. In this way you are always writing one ROI ahead.

It's a tricky concept - I'm always getting it wrong. But think of it this way... the registers are written to the chip but do not take effect until the next range starts.

Knowing this one sets up the first range parameters and issues the start, then once you are sure the range is running - a couple of ms later, write the next parameters, then read the result of the first range.

Good luck,

• john

[PChat.1]

Thanks a lot.

With your help, it is now working!

[PChat.1]

Hello,

I am opening this topic again because I'd like to use measurement of 16 4-by-4 ROI zones to cover the full field of view of the sensor. I think I understood the operating mode of the sensor, measuring in continuous mode, the offset between the ROI setting and the result of the measurement.

I read also that it was no ideal to change drastically the ROI region from one measurement to the next one. So I coded the measurements to cover all the ROI by going left-right-up-righ-left... across the 16 ROIs, and then reverse.

What I observe is as follows : 

for a steady target, the values are significantly different between the forward measurement of the 16 ROI and the backward (more than 10 cm for a target at around 40 cm). But forward measurements are pretty stable, as well as backward

I observe also that the first measurement on the top-left or bottom-right is odd, giving anormally high value.

So when displaying the results on a 3D graph, we see a spike in one corner and oscillations of the surface corresponding to forward and backward measurements.

To try to initiate the sensor, I tried successively to :

• make a first measurement full frame (16*16 SPADs), prior to each sequence of 16 ROI measurements
• measure each ROI twice
• change the MeasurementTimingBudgetMicroSeconds, the intermeasurement period, the distance mode from short to medium,...

Any idea that could help ? any code that would work normally ?

Thanks again for your help

[John E KVAM]

​The reason your 'corners' are off is that the cone of light floods a 27 degree cone, but the SPAD detector is a square array. If you draw a circle with the largest square you can draw inside it, you will see the problem. The 'sides of the square have illumination all round, but the corners have edge effects.

The solution to your issue is that you must do an offset calibration (and perhaps a crosstalk calibration if you have a coverglass) on EACH zone you plan to use.

Changing between 'short' and 'medium' you should see that short is more accurate. Longer distances require that the pulses of light need more time between them, so in any given period there will be fewer.

I cannot think of a reason 'forward' would be different from 'backward'. The same light goes out and the same light presumably comes back. The only difference is which SPADs in the array are enabled.

I'm going to guess (hope perhaps) that if you do an offset calibration for each zone you plan on using, the artifact will go away.