VL53L5CX out of range values not returning to 0 for zones that are looking into open space areas, has anyone else seen this issue?

[SMcAn.1]

I’ve used the VL53L1X and found it to be very reliable, I obtained a few VL53L5CX the (Sparkfun Breakout version) for assessment to a particular project.

A similar issue has been logged on the Spark fun forum a couple of years ago without any resolution.

I’m not sure if this issue has been resolved with later firmware and I’m not sure if the issue is with the VL53L5CX firmware or the Spark fun Library? (but there hasn't been an update to the Sparkfun Lib in quite some time).

I don’t know of any other mulit-zoned ToF sensors like the VL53L5CX, so I really want to use this sensor for the project.

The locations that require this sensor, are large rooms, 4 meters x 4 meters or grater , the sensor would be mounted in an enclosure and sited to a fixed location at low level looking into the room.

when the sensor is first initialized the data returned for all zones that are out of range (greater than the sensors max read range) is 0 and this is not a problem. I think its was -1 with the VL53L1X…

(In the following images I’ve substituted the actual values for 0 & 1 just for simplicity.)

When a person appears within the sensor FOV and within range, the sensor then returns the range for the subject in view.

However, when the target subject moves out of the sensors range and field of view, the previous values remain. They don’t return to 0.

Zones that are within range do return to their pervious value.

I've tried all three of the sensors I have with the Sparkfun sample code and library and its the same for all three.

I’m assuming that the measurementData array isn’t being cleared prior to the next getRangingData and its just filling values that are present into the array??

Any help would be appreciated...

Thanks.

[AlexCloned]

Hello @Steven McAnena​ : Let's see what ST staff answers.

In the meantime, I believe I have a quick answer for you.

I think the Sparkfun sample code and library ultimately call functions from the ST API contained in the ULD driver (Ultra Light Driver). If you browse through the source code of vl53l5cx_api.h, you will find the following structure:

typedef struct
{
...
	/* Number of valid target detected for 1 zone */
#ifndef VL53L5CX_DISABLE_NB_TARGET_DETECTED
	uint8_t nb_target_detected[VL53L5CX_RESOLUTION_8X8];
#endif
 
...
	/* Measured distance in mm */
#ifndef VL53L5CX_DISABLE_DISTANCE_MM
	int16_t distance_mm[(VL53L5CX_RESOLUTION_8X8
					*VL53L5CX_NB_TARGET_PER_ZONE)];
#endif
...
	/* Status indicating the measurement validity (5 & 9 means ranging OK)*/
#ifndef VL53L5CX_DISABLE_TARGET_STATUS
	uint8_t target_status[(VL53L5CX_RESOLUTION_8X8
					*VL53L5CX_NB_TARGET_PER_ZONE)];
#endif
...
} VL53L5CX_ResultsData;

I'm only mentioning the fields of interest, where you (on your own) may find the clue.

More specifically, if you map the target_status and discard the results where an error code of 255U is returned (indicating no update for distance), you will be able to eliminate those zones that are not providing data after the object (or person) moves away. This is common when walls are too far, almost out of range, and/or when ambient light conditions prevent the sensor from obtaining an accurate measurement after the target moves. In harsh conditions, measurements may take several attempts.

By the way, you should also try increasing the integration time (lowering the sampling frequency) of the sensor. This enhances the results in difficult and high ambient light noise conditions. By doing so, you will obtain fewer "no-updates" in the sensor results.

Regards.

[SMcAn.1]

Hello @AlexCloned Thanks for your reply...

Last time I tried logging in the site was down for maintenance.

I am surprised this issues has not been raised before and I'm also surprised that ST Staff haven't commented 

Ill take a look at your areas of interest and up date this post at another time... Thanks Again.

[Anne BIGOT]

Hello,

Thank you for your interest for ST products and sorry for the delay to get answer to the questions.

The way it is working is you have to check number of targets, target status and only use valid data. Hope this helps.

Regarding other MultiZone sensors, we just introduce the VL53L7CX and VL53L8CX. You can find them on st.com

Regards

Anne

[John E KVAM]

The issue is that we allowed a hardware designer to spec the return. 

Instead of zero'ing the return buffer - as one should - he just overwrote it.

So the correct way to deal with the buffer is:

if there is at least one target, and the target status is valid, then use the distance, else return some arbitrary large number.

That should give you what you want