VL53L1 UltraLite driver function VL53L1X_GetXtalk returns always 0

[Fabian1]

I am using the function VL53L1X_SetXtalk to set the crosstalk value. When I want to read back the crosstalk value with the function VL53L1X_GetXtal, this function returns always 0.

[Fabian1]

I have further investigated this bug and I found out that the function VL53L1X_GetXtalk uses VL53L1_RdDWord for reading out the crosstalk value.

But what I see is that this register is only 16 bits wide. So I have changed two lines in the function VL53L1_GetXtalk and now it works:

uint16_t tmp;
status = VL53L1_RdWord(dev,ALGO__CROSSTALK_COMPENSATION_PLANE_OFFSET_KCPS,&tmp);

Could anyone else confirm this workaround?

[John E KVAM]

​The latest software in the Ultra light driver contains your fix.

I'm guessing you were not the only one to find the bug.

VL53L1X_ERROR VL53L1X_GetXtalk(uint16_t dev, uint16_t *xtalk )
{
	VL53L1X_ERROR status = 0;
	uint32_t tmp;
 
	status = VL53L1_RdDWord(dev,ALGO__CROSSTALK_COMPENSATION_PLANE_OFFSET_KCPS, &tmp);
	*xtalk = (uint16_t)(tmp*1000)>>9; /* * 1000 to convert kcps to cps and >> 9 (7.9 format) */
	return status;
}

[LWOEI.1]

Hi Guys, a question here, i wonder if i install VL53l1X at shower room to detect falling , will it affected by steam or hot environment?

[John E KVAM]

this is such a good question, I'm going to place it as a new query instead of putting it at the bottom a this thread.

[Hardwariano]

Hello @John E KVAM​ ,

I have the same problem as @Fabian​ . That code doesn't work for me. After debugging and much trial and error, this is the code that works for me:

*xtalk = (uint16_t)((tmp*1000)>>25);

The reason I right shift 25 is that tmp is uint32_t and first 16 bits are zero. So 9 + 16 = 25:

tmp = b31 b30 b29 b28 b27 b26 b25 b24 b23 b22 b21 b20 b19 b18 b17 b16 0000 0000 0000 0000. Where:

• [b31..b25] = Crosstalk value that matches the value calculated by VL53L1X_CalibrateXtalk().
• [b24..b16] --> 9 bits shifted as ST API for VL53L1X indicates.
• 0000 0000 0000 0000 --> 16 bits that I don't know where they come from, but must be shifted to get the correct crosstalk value from sensor internal's memory.

Am I right?

Regards