Problems calibrating VL53L0X ToF distance sensor (VL53L0X_perform_offset_calibration, VL53L0X_perform_xtalk_calibration). bug?

[GPodr.1]

Routine

VL53L0X_perform_offset_calibration from src/core/src/vl53l0x_api_calibration.cpp is giving strange results. By my opinion the problem is in uint16_t sum_ranging which should be of type uint32_t due to later bit shifting (<<16), which needs to be done due to fixed point arithmetics.

(I was performing this calibration at 270 mm distance, which is due to documentation not optimal one, but after the fixes it works fine).

In case of VL53L0X_perform_xtalk_calibration the same goes for multiple variables (sum_ranging, ...) that accumulate the range measurements performed by the routine. Unfortunately there are some other errors present due to which the calibration routine doesn't produce an appropriate XTalkCompensationRateMegaCps value. Due to the lack of understanding what this calibration routine is trying to compute, I am not able to figure it out why.

(I was performing this calibraton at 600 mm distance).

Am I doing something wrong?

[John E KVAM]

The Xtalk works by comparing the actual distance (which you supply) with the range that the device gets.

At short distances the Xtalk has little effect as the relatively few Coverglass reflected photons get averaged with a huge number of target reflected photons.

But as the distances increase the Coverglass reflected ones start averaging with fewer and fewer target reflected ones until a plot of the distances starts looking like a parabola. (At some point all the photons returned will be from the coverglass and the distance would be 0.)

Knowing what this curve looks like, and knowing what the right answer is allows us to make an educated guess at the number of photons bouncing off the coverglass.

I had a guy complain we were doing some signed right shifts that didn't work. (Some MCU do logical right shifts, some do arithmetic.)

I checked that and didn't see anything.

I saw a 16-bit unsigned accumulator (sum_ranging), but we range 50 times (to get an average) but 50 * 600 is only halfway to 65536, so that should be fine. The FixPoint1616 are actually 32 bit values, so they should be fine. And EffectiveSpadRtnCount is can never be as high as 256, so that should be fine as well.

Did you get an error number for your calibration? What was it?

Could you post your correction to the offset? I can have it incorporated in newer releases.

• john

[GPodr.1]

Hi, thank you very much for your question.

In case of:

VL53L0X_perform_offset_calibration

(vl53l0x_api_calibration.cpp)

the problem by my opinion is in line 255:

StoredMeanRange = (FixPoint1616_t) ( (uint32_t)(sum_ranging << 16) / total_count);

As sum_ranging is of 16 bit type, shifting it left by 16 produces zero. Some compilers would predict the problem and cast the variable to 32 bit, mine does not.

A better way to do that would for example be:

StoredMeanRange = (FixPoint1616_t) ( ( (uint32_t) sum_ranging) << 16) / total_count);

or having the sum_ranging be of 32 bit type.

There are multiple similar problems in case of VL53L0X_perform_offset_calibration.

I don't get an error return value, but the values that calibration routines produce are not improving the measurements (have checked that without any cover glass). With fixes, the offset is working, but xtalk, that does some additional calculation, does not. I managed to find a value, through an optimization, which improves the distance measurement when fed to VL53L0X_SetXTalkCompensationRateMegaCps. This value is different than the one produced by the calibration routine.

I know the coverglass problem and was testing the routines with and without it. Both unsuccessfully.

Not related to the original topic, but anyway :)

For our current application, we have to put a cover glass with thickness of 12 mm in front the sensor -> it is a demand by our customer.

I don't even get a parabola, I just get a straight line, whatever the real distance to the object is.

real distance 300 mm, measured distance 270

real distance 700 mm, measured distance 270

...

When no glass is present, I get the right measurements.

I guess that most of the light reflects from that glass, which is just to thick for this sensor.

[John E KVAM]

​12mm is a lot. But I saw a design from CrutialTec that might work for you.

http://www.crucialtec.com/contact?lang=en

It's the same ST sensor in there, but some pretty fancy optics spread the Tx and the RX. I'm thinking this would be impervious to crosstalk.

I don't see this device on their website, but I'd contact them and ask.