VL53L8CX - Unable to use detection thresholds while in Autonomous mode.

[simonbelanger]

Hello,

I have been using the this ToF sensor along an ESP32-WROOM MCU for a while without major issues. My impementation of the i2c interface seems to be working well since in most simple ranging cases everything works well.

However, recently, i have been playing around with detection thresholds. I discovered that when I enable detection thresholds while in autonomous mode, I am unable to start ranging. In fact, the sensor gets properly configured (resolution, ranging mode, integration time, frequency and detection thresholds) but when it starts ranging (function vl53l8_start_ranging), error VL53L8_STATUS_ERROR occurs. The error gets raised in this part of the function

 

	/* Read ui range data content and compare if data size is the correct one */
	status |= l8_dci_read_data(p_dev,
			(uint8_t*)p_dev->temp_buffer, 0x5440, 12);
	(void)memcpy(&tmp, &(p_dev->temp_buffer[0x8]), sizeof(tmp));
	if(tmp != p_dev->data_read_size)
	{
		status |= L8_STATUS_ERROR;
	}

 

because the data that is read has a size of zero (tmp is zero). 

However, I have no clue why this is happening since the Smart Person Detection code implements such a configuration (Autonomous 4x4 with low power consumption and detection thresholds). And when i disable detection thresholds while in autonomous it works well. Also, when i enable detection thresholds while in continuous mode, it also works well.

Do you have an idea why this is happening?

 

Note that at first, I was using ULD driver version v1.0.4 but i also did some testing with version v2.0.0 and also with the universal driver VL53LMZ_ULD_API_v2.0.10. In all my tests, I was unable to properly configure the sensor.

[John E KVAM]

When playing around with threshold detection, do you only get the interrupt when something gets below the threshold point?

If I read your complaint correctly (not completely likely) you are reading zero bytes.

That's what might happen if you read the buffer before the interrupt triggers. Would that be possible?

Because you can set up to 64 interrupts on so many different items, one would be left wondering if they were configured correctly. 

Put a breakpoint on the interrupt-service routine and convince yourself that the interrupt was indeed firing correctly. Then we can worry about why you are not reading the data that you should be.

I always hate answering questions with questions, but I don't have any other great ideas. 

- john

[simonbelanger]

Ok, thanks for your quick response.

I think the issue on my side was that i was catching errors on vl53l8cx_start_ranging() function (header below) and restarting the sensor booting process (reset sensor, init sensor, configure, etc) when errors occured. Since I was reading zero bytes, an error would always occur. Because the sensor was constantly rebooting, this meant that i wouldn't let the interrupts trigger correctly, even if they were properly setup.

 

/**
 * @brief This function starts a ranging session. When the sensor streams, host
 * cannot change settings 'on-the-fly'.
 * @PAram (VL53L8CX_Configuration) *p_dev : VL53L8CX configuration structure.
 * @return (uint8_t) status : 0 if start is OK.
 */

uint8_t vl53l8cx_start_ranging(
		VL53L8CX_Configuration		*p_dev);

 

If instead I don't check the return value from vl53l8cx_start_ranging(), the code works as expected : I get data and interruptions when motion is detected in front of the sensor. Which is good!

 

Then, I don't get why there would be a difference in using Continuous mode and Autonomous mode? In both cases, when the ranging starts, I should read zero bytes if my interrupt configuration is the same. However, it seems that in Continuous Mode, start_ranging does not return errors. For reference, other options are 4x4, 2ms integration, 10 Hz rate.

Also, I don't get why start_ranging would return an error that I should ignore? 

 

 

[John E KVAM]

In order to duplicate your issue I need to know how much data you expected the sensor to send you. 

That's what is #defined in your platform.h.

It's the:

// #define VL53L8CX_DISABLE_AMBIENT_PER_SPAD

// #define VL53L8CX_DISABLE_NB_SPADS_ENABLED

// #define VL53L8CX_DISABLE_NB_TARGET_DETECTED

// #define VL53L8CX_DISABLE_SIGNAL_PER_SPAD

// #define VL53L8CX_DISABLE_RANGE_SIGMA_MM

// #define VL53L8CX_DISABLE_DISTANCE_MM

// #define VL53L8CX_DISABLE_REFLECTANCE_PERCENT

// #define VL53L8CX_DISABLE_TARGET_STATUS

// #define VL53L8CX_DISABLE_SCI

My working assumption is you uncommented a combination of these that we did not test and the calculation of the buffer size is not working. 

Tell me how you have these configured and I can try to duplicate the issue.

- john

 

[onderdelen]

Hi,

 

I had the same issue as you. Commenting out my logic to block starting when the return code was not 0 made me realise the thing actually worked.

What I found out is that if you holds an object within the threshold distances during ranging start, the routine starts with status code = 0.