Questions regarding VL53L1 TOF sensor and API

[mf101]

While evaluating the VL53L1 TOF sensor the following quetions arose. Thanks in advance for any feedback.

- The full featured API provides functionality known as RefSPAD calibration (missing in UltraLite API), which is suggested to be used when adding a cover glass on top of the sensor. Is there a strong benefit using this function or is it negligible ?

- Does XSHUT=0 perform a full hardware reset (including the I2C logic) ?

- Is it possible to use a ROI of 2x8 or 1x8 size ? If yes, are there any restrictions regarding configuration parameters like e.g. preset mode ?

- Is it possible to clean a PCB with a VL53L1 with PCB cleaners without harming the sensor ?

- The following parameters in VL53L1_CalibrationData_t are not mentioned in UM2133 regarding calibration, are they missing in the documentation or not required ?

 customer.global_config__ref_en_start_select

 ref_spad_char__total_rate_target_mcps

 xtalkhisto.xtalk_hist_removed

 algo__xtalk_cpo_HistoMerge_kcps

 add_off_cal_data

- According to UM2133 only when using VL53L1_PerformOffsetCalibration() all preset modes are supported, is this true ?

 Which preset modes are supported with VL53L1_PerformOffsetZeroDistanceCalibration() ?

- In general, is it necessary to perform calibration for each of the preset modes individually or is it possible to use one set of calibration data for all preset modes ?

- Are there any side effects between crosstalk and smudge correction or can both be enabled at the same time ? Is smudge correction only possible with histogram based preset modes ?

- Configuring the limit check values VL53L1_CHECKENABLE_SIGMA_FINAL_RANGE and VL53L1_CHECKENABLE_SIGNAL_RATE_FINAL_RANGE with VL53L1_SetLimitCheckValue()

 causes wrong measurement results with ranging/scanning preset modes. Is the limit check not intended to be configured in these preset modes ?

- When using the ranging preset mode the measurement results in some situations were not as stable as when using the VL53L1X UltraLite API. E.g. with 17% reflectance target at a distance of 1.8m the distance values were wrong but reported with status=0 (OK). In general, distance mode medium yielded better results than long which does not match with UM2133 (according to this medium should be better).

 It also seems like the ranging preset mode is prone to mutual influence. Two sensors operating in this mode and facing the same target corrupt each other’s measurement, yielding wrong ranging results.

 The described behavior was observed both with ST standard Nucleo hardware / GUI and a custom hardware design / custom software. Is there any possible explanation for this behavior ?

[John E KVAM]

There are 3 drivers for the L1 sensors. The UltraLite, which does not expose the full capability of the chip, but is good enought for most designs. The 'Full driver', and the Histogram driver - which runs on the VL53L1CB chip. These question seem to be coming from someone who has really studied all three.

- The full featured API provides functionality known as RefSPAD calibration (missing in UltraLite API), which is suggested to be used when adding a cover glass on top of the sensor. Is there a strong benefit using this function or is it negligible ?

This is an oversight - but not a really bad one. The sensor was RefSPAD calibrated at the factory. But during reflow it could change, so we recommend doing the refspad, but in reality it rarely changes, and it's not that bad if it's slightly off.

- Does XSHUT=0 perform a full hardware reset (including the I2C logic) ?

Resets everything. If you have several sensors in reset, you can bring them out one at a time, and change their addresses.

- Is it possible to use a ROI of 2x8 or 1x8 size ? If yes, are there any restrictions regarding configuration parameters like e.g. preset mode ?

the only rules are the ROI must be rectangular and at least 16 SPADs. So 2x8 is ok. 1x16 is also OK. 1x8 is not.

- Is it possible to clean a PCB with a VL53L1 with PCB cleaners without harming the sensor ?

Cleaning around the sensor is NOT recommended. There is a void between the filter and silicon. In order to prevent the chip from exploding during reflow there is a vent. Better not to get chemicals near there. Some people put a tempory cap over the sensor durning cleaning. That seems to work.

- The following parameters in VL53L1_CalibrationData_t are not mentioned in UM2133 regarding calibration, are they missing in the documentation or not required ?

 customer.global_config__ref_en_start_select

 ref_spad_char__total_rate_target_mcps

 xtalkhisto.xtalk_hist_removed

 algo__xtalk_cpo_HistoMerge_kcps

 add_off_cal_data

I don't think we do a really good job of removing variables in structures that may have become obsolete. We use the driver to refine the sensor's usage, and as soon as we are satified with the operation we go into production. There is always a desire to "leave it in there - we might need it later". In every calibration I've seen, these are always =0.

- According to UM2133 only when using VL53L1_PerformOffsetCalibration() all preset modes are supported, is this true ?

Yes, you are tuning to the clock phase, which is constant.

 Which preset modes are supported with VL53L1_PerformOffsetZeroDistanceCalibration() ?

I don't know that function. A typo perhaps?

- In general, is it necessary to perform calibration for each of the preset modes individually or is it possible to use one set of calibration data for all preset modes ?

Ideally you should have an offset for each. but that's hard to maintain. You might do will with just one 'averaged' calibration.

- Are there any side effects between crosstalk and smudge correction or can both be enabled at the same time ? Is smudge correction only possible with histogram based preset modes ?

Crosstalk comes from photons that hit the coverglass, and bounce back. A smudge on this glass will reflect more photons and increase crosstalk. Left unchecked one might get a 'ghost image'. Smuge correction dynamically changes the amount of crosstalk. Crosstalk is corrected when there is reasonable assurance there is no near target. But if you always have a target the crosstalk will not be corrected.

- Configuring the limit check values VL53L1_CHECKENABLE_SIGMA_FINAL_RANGE and VL53L1_CHECKENABLE_SIGNAL_RATE_FINAL_RANGE with VL53L1_SetLimitCheckValue()

 causes wrong measurement results with ranging/scanning preset modes. Is the limit check not intended to be configured in these preset modes ?

Adjusting these parameters will cause the status of the range to change if your sigma is too height, or if your signal rate is too low. it might cause the range to end early and not complete, but I was not aware it did anything but change the status.

- When using the ranging preset mode the measurement results in some situations were not as stable as when using the VL53L1X UltraLite API. E.g. with 17% reflectance target at a distance of 1.8m the distance values were wrong but reported with status=0 (OK). In general, distance mode medium yielded better results than long which does not match with UM2133 (according to this medium should be better).

I think you have a typo there. "medium yielded better"... "medium should be better".

So I don't quite understand the question.

But a 17% target at 1.8m is going to be very challanging, and some modes might work better than others.

 It also seems like the ranging preset mode is prone to mutual influence. Two sensors operating in this mode and facing the same target corrupt each other’s measurement, yielding wrong ranging results.

 The described behavior was observed both with ST standard Nucleo hardware / GUI and a custom hardware design / custom software. Is there any possible explanation for this behavior ?

if you allow enough time for the sensors to adjust to odd ambient situations, you will do better. I have seen where the sensors interfer with each other, but only if the sensors are very close, and the timeing budget is very short. Can you afford a longer timing budget?

[mf101]

Thanks for your feedback.

RefSPAD

Can you give some rought explanation what the RefSPAD actually does ? I found some illustration about the internal structure of the sensor, but it is only mentioned that the RefSPAD is located close to the VCSEL and there are optical coupling paths.

So 2x8 is ok. 1x16 is also OK. 1x8 is not."

I was unable to configure 2x8 with the function VL53L1_SetROI(), it seems like the API limits the minimum height / width to 4. Is there any other way to use 2x8 or 1x16 ?

I don't know that function. A typo perhaps?

VL53L1_PerformOffsetZeroDistanceCalibration() is mentioned in UM2133 chapter 7 and exists in vl53l1_api.h.

I think you have a typo there. "medium yielded better"... "medium should be better".

You are right, there was a mistake in my final question context: I experienced that the medium distance mode performed worse than the long distance mode.

In our application scenario it is absolutely vital to get a stable distance measurement without erroneous outliers. Unfortunately, I was not able to achieve this with the histogram based preset modes.

In theory they should perform better, but in practical evaluation the delivered performance was worse (mutual influence between sensors, less stable measurement, spontaneous erroneous measurement) in all distance modes in comparison to lite ranging / autonomous.

Details of the measurement setup:

-         VL53L1 API 6.6.1

-         VL53L1 without cover glass centered to the reflector

-         17% reflector (59x59cm) placed at distances up to 2m

-         Preset mode ranging

-         ROI16x16 and timing budget 100ms (long and medium distance mode), 15ms (short distance mode)

In medium distance mode there are situations where the sensor reports a valid status but the distance values are wrong, e.g.:

-         at a distance of 1.6m status=7 and wrong measurement values

-         at a distance of 1.9m status=0 and wrong measurement values

-         at a distance of 2m status=0 and wrong measurement values

In short distance mode the sensor reported status=4 beginning at a distance of 1m, which is worse than the 1.3m I can achieve with the preset modes lite ranging / autonomous in short distance mode.

But a 17% target at 1.8m is going to be very challanging, and some modes might work better than others.

Autonomous / lite ranging mode work fine at this distance, but histogram based preset modes not (see above).

I have seen where the sensors interfer with each other, but only if the sensors are very close, and the timeing budget is very short. Can you afford a longer timing budget?

All our products will run with the same timing budget, it is configurable but the default value is fixed. Unfortunately even with longer timing budget the mutual influence could be observed.

For better understanding: Is the mutual influence caused due to longer measurement and therefore increased probability of temporal interference ?

In ranging / autonomous preset mode there seems to be no mutual influence or it is very unlikely.

[John E KVAM]

Instead of measuring the start time from laser power up, we measure the start of photons being generated by when the reference array start seeing some light we diverted from the transmitter. Setting the refSpad was to tune the number of SPADs we used. Turns out the factory setting always works, so I've mostly given up on running the refspad calibration.

I stand corrected, the datasheet says:

ROI size and position are programmable: the user may chose a custom FoV from 4x4

SPADs (minimum size) up to 16x16 SPADs (full FoV).

Medium sends more pulses of light per ms than does long range, but it gives up the max distance in order to do so. I'm guessing that is what you be by lesser performance.

Google "Radar aliasing". It will explain the problem. There are wrap distances were the light from pulse A comes back after the light from pulse B goes out. The sensor does not know which pulse is which giving the aliased distance. So you cannot use short or medium for distances longer than the spec in the data sheet. You will get the wrong answer. Status 4 is "Wrap Check" which would be better worded as "aliasing failure".

The interference is only seen as the very short distances. At anything longer, the sensor appear as ambient light to each other.

• john

[mf101]

Thanks for the clarification of the ROI size.

Regarding the medium distance mode:

With long distance mode I can measure up to 2m, in medium distance mode not. This is the case for both custom hardware and Nucleo standard hardware with ST GUI. I don't see status 4, but sometimes status 0 (no error) with wrong measurement values.

According to AN5573 medium distance mode should perform better than long distance mode in ranging preset mode, e.g. max. distance with 17% reflector of 3.5m vs 3.2m. Maybe this is a documentation error ?

[John E KVAM]

According to AN5573 medium distance mode should perform better than long distance mode in ranging preset mode, e.g. max. distance with 17% reflector of 3.5m vs 3.2m. Maybe this is a documentation error ?

No, that is correct.

And it will, assuming you don't go past the max range of the mode you are in, and your target fills the entire FOV. (So at 3.5M is your target 1/2 of the 3.5M in diameter?)

ideally one wants to send out as many pulses of light as one can. But one has to wait for the light to go out to the max distance, reflect and travel back.

In short mode we send out pulses assuming the light will travel only to a max of 1.2M. So we can send out lots of pulses. If we have to wait for the light to go to a max of 4 meters, we can only send out 1/3 fewer pulses.

The distance you can range depends on the number of pulses, but also on the reflectivity and size of your target. But generally short has more pulses and works better than long, but medium and long have the ability to range farther.

To get a good explaination, google "Radar Aliasing".

So choose the disance mode based on your longest anticipated target range.

In the latest releases in Histogram mode in the L1CB and L3CX sensors we cheat a little bit.

We know the wrap points and we actually use two different timing intervals. This allows us to make some assumptions, and post process the data.

So in histogram mode only, we can use the higher number of pulses of 'Medium" mode, and evaluate the data to determine if there was a wrap.

We can un-wrap the wrap and get a good number at a farther distance that one might expect.

Please note that this does NOT work for the other modes. The other modes don't have the advantage of being able to post process the raw data.