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

[simonbelanger]

I have this configuration

#define VL53L8CX_DISABLE_AMBIENT_PER_SPAD
#define VL53L8CX_DISABLE_NB_SPADS_ENABLED
#define VL53L8CX_DISABLE_NB_TARGET_DETECTED
//#define L8_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_MOTION_INDICATOR

[John E KVAM]

Ah, there you have it. 

You absolutely need 

VL53L8CX_DISABLE_NB_TARGET_DETECTED

defined. 

And here is why...

To verify any range, you need some logic that looks like:

If number of targets is at least 1 and the RangeStatus for that target is 5, 6, 9 (and sometimes 12) Then and only then do you have a valid target. 

So put number of targets detected back in and see if you get going. 

It costs you 64 bytes, but you could disable the motion flags to gain that back.

- john

[simonbelanger]

I tried reenabling the number of targets detected by commenting the macro 

#define VL538CX_DISABLE_NB_TARGET_DETECTED

however, I still get an error while starting the sensor using vl53l8cx_start_ranging(). The value of p_dev->data_read_size has increased accordingly and is now 792 Bytes but the value it compares to, namely 'tmp', which is queried from the device, is still 0 at that point in the function.

	status |= vl53lmz_dci_read_data(p_dev,
			(uint8_t*)p_dev->temp_buffer, 0x5440, 12);
	(void)memcpy(&tmp, &(p_dev->temp_buffer[0x8]), sizeof(tmp));
	ESP_LOGI("api", "tmp %"PRIu16", rdsize %"PRIu32"", tmp, p_dev->data_read_size);
	if(tmp != p_dev->data_read_size) {
		status |= VL53LMZ_STATUS_ERROR;
	}

Am I missing something?

But as mentionned before, If i ignore the return status of vl53l8cx_start_ranging(), the sensor is usable and it triggers interruptions as expected. 

Also, I just found this issue in the forum that looks like mine. It is probably a duplicate. VL53L5CX _start_ranging() fails with 255 error - STMicroelectronics Community.

[John E KVAM · Accepted solution]

You need as a minimum:

// #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_MOTION_INDICATOR

It's 1327 bytes, and you can remove AMBIENT, but that's only saving 8 bytes - and it can come in handy. 

To verify a valid target, you need NB_Target >0 AND TargetStatus =(5, 6, or 9) , Then you can print DistanceMM.

I don't know if our code was verified using less than that. 

- john