VL53L1X temperature effects

[Brettjohnson7191]

We placed two VL53L1X sensors at 18.6" in our temperature chamber. 

Over a 50C swing we saw up to 1.15" of variability. In the images bellow the chamber temperature stabilized around 30 minutes. 

The target was a large 24x24 sheet of white nylon 0.5" thick

The sensors were left on the entire time, polled every 10 seconds.

SPAD ARRAY size 8x8

Is there any way to improve this? Is it possible to access the temperature registers on the VL53L1x so we can create a variable to compensate for the temperature induced error? 

[John E KVAM]

Assuming you are using the STSW_IMG009 - UltraLite driver.

To save time for each range we limit the amount of temperature compensation we do. 

Look at the init function :

VL53L1X_ERROR VL53L1X_SensorInit(VL53L1_Dev_t dev)
{
	VL53L1X_ERROR status = 0;
	uint8_t Addr = 0x00, tmp=0;

	for (Addr = 0x2D; Addr <= 0x87; Addr++){
		status = VL53L1_WrByte(&dev, Addr, VL51L1X_DEFAULT_CONFIGURATION[Addr - 0x2D]);
	}
	status = VL53L1X_StartRanging(dev);
	while(tmp==0){
			status = VL53L1X_CheckForDataReady(dev, &tmp);
	}
	tmp  = 0;
	status = VL53L1X_ClearInterrupt(dev);
	status = VL53L1X_StopRanging(dev);
	status = VL53L1_WrByte(&dev, VL53L1_VHV_CONFIG__TIMEOUT_MACROP_LOOP_BOUND, 0x09); /* two bounds VHV */
	status = VL53L1_WrByte(&dev, 0x0B, 0); /* start VHV from the previous temperature */
	return status;
}

It's line 16 that limits the amount of temperature drift we account for. This saves time, but only works if the temperature drift is slow. 

If you have fast changes in temperature, you can stop the chip and re-initialize it. 

Or you can simply remove line 16 and leave the full temperature compensation active. 

if you are using the full driver (STSW_IMG007), look for the VHV functions. It will allow you to set the amount of temp change you account for. 

but if you change this allow a few more milliseconds for each range. It does take longer. 

[Brettjohnson7191]

Removing line 16 shows no improvement across temperature. I assume the overshoot at the -10C to 40C transition is the temperature correction in the VL53L1x chip. However it just does not seem to be able to handle the rapid change in temp. Any further thoughts?

[John E KVAM]

that data looks the same to me. Yet I'm believe you did change the thing I asked you to. And that make no sense to me.

Could you try putting line 16 back in (undoing the change) then stopping the range, re-initializing the sensor and restarting. Do that every now and again. Perhaps once per few degree changes. 

It should get a little off as the temp changes and then snap back as the chip re-compensates during the init. I would think you could see it on your graph. 

Then you could leave it like this - if you have the time, or we could dig into why it wasn't working.

I don't have a temp chamber available, or I'd give it a try. 

Maybe you have to remove line 17 as well as 16. It's really all I can think of.

- john

[Brettjohnson7191]

Running this test again with the software modifications, results are above. Still no change in this issue.

Our process is as follows upon first start up we initialize the sensors

Set I2C addresses

wait for sensors to boot

initialize sensors

set distance mode to short

set timing budget to 200ms

set inter measurement to 200ms

set offset cal

set xtalk cal

set ROI to 16x16

set ROI center to 199

Then we start taking measurements in 10 second intervals

Each data point we start ranging take 10 measurments, stop ranging and use the average of these as our reported distance. 

If temperature changes by 5C we reinitialize the sensors using the same routine described above. 

Shown in the test above we held at 20C for 2 hours dropped down to -10C at 1 degreeC per minute held this for 2 hours. Jumped up to 20C at 1C/min held this for 2 hours. Jumped up to 40C at 1C/min held for 2 hours then dropped down to 20C held at 1C/min. As you see we are still over an inch of temperature induced offset between -10 and 40C

I can run this test again by commenting out line 16 and 17 of the SensorInit function as stated before.

VL53L1X_ERROR VL53L1X_SensorInit(VL53L1_Dev_t dev)

[Brettjohnson7191]

above plot shows the sensors from 20C down to -10C at 1 degree C/min intervals and then holding at -10C

software configuration in this was the same other than line 16 and 17 being commented out. 

[John E KVAM]

I just got the results from my expert in Asia. He says, 

• Re-initializing the sensor will help to remove the drift.
• Reboot sensor will help to remove the drift.

So if you can afford the time, apparently restarting whenever you think there is a temperature shift will help the issue. 

There is some work done at boot time that calibrates the reference SPADs and VHV voltages that apparently drift with temperature. 

- john

[Brettjohnson7191]

As shown above re-initializing the sensors showed no effect in compensating for the drift in our setup

Rebooting the sensors I haven't tried yet, looking through the API there doesn't appear to be any way to reboot the sensors over I2C? We did not implement any methods of toggling power to the sensors and XSHUT was only connected with one sensor to set the I2C Addresses.  

I can run a test from room temp down to -10 and manually reset the entire setup and see where the temperature comes back too.  

We did run a sweep shown here, starting at 20C we dropped down to -10 at 1degreeC/min then every hour we increased 5 degreeC up to 40C. The error is still outside ST's specs but appears to be relatively linear and correctable if we add a temperature sensor onto the TOF sensor board itself.

[Tom_pm]

Interesting experiment. I am new to these sensors but that should indeed be mostly an offset error.

Looking at your diagram that would be around 1.2inch ~= 30mm over the 50°C change giving around 0.6mm per °C.

Didn't see any value specified for the VL53L1X, but for the VL53L4CX they mention an offset change of 1.3mm/°C in the ranging performances section of the datasheet. Maybe an ST expert can share what offset correction value they are using for this sensor.