TOF VL53L5CXV0DH/1 bad detections with status 255

[sde c.1]

I’m using a VL53L5CXV0DH/1 sensor in my current setup (see pictures). The goal is to detect a ball rolling between the sensor and the background. The red box is about 12cm apart.

The settings is 4x4 for speed, i also noticed that 60 is not the highest scan frequency 

in code : status = vl53l5cx_set_ranging_frequency_hz(&dev,60);

if i set 120 this works too, while scanning seems to be lot faster and just as accurate, why is 60 defined as maximum in the datasheet?

However (even at 60), I often see target_status = 255 for 3-4 pads, without the ball passing and wonder why this happens. When this occurs, the distance information is apparently correct but the datasheets states that the distance readings become unreliable, and I want to ensure I get the most accurate and dependable measurements.
When the ball passes i see 255 in even more status records.

What could be causing this issue?

Additionally, I’d appreciate any advice on settings or adjustments to improve detection, especially for reflective plastic balls passing through the sensor's field of view.

 

Based on the readings in distance_mm and target_status:

• Values 12-15 correspond to the desk near the sensor.
• Values 8-11 represent the next row of the 4x4 matrix.
• Values 0-7 accurately measure the red box at the correct distance.

However, I’m puzzled why values 8-11 are so unreliable. If the issue is related to the object being horizontal, it would make sense only if values 12-15 also returned 255.

Any insights would be appreciated.

Thank you,
Steve

[John E KVAM]

When you place the sensor at the edge of the table like that, some of the zones that shine on the table at nearly a zero angle are going to be problematic. Some photons well return at nearly a zero distance, and some will see your red target. But the sensor kind of expects all of them to mostly come from a single place. So, the standard deviation of the result is going to be halfway between 0 and 120 with a standard deviation of 60 or so. The sensor doesn't know what to do and returns a 255 status. 

So you see some zones at near zone - because they are pointing down, and some at 134 because they are pointing at a target. But the zones in the middle are just lost. And unless your table is heavily textured, the photons are just bouncing away and not returning. 

I hope that helps.

- john

[sde c.1]

Hi John,

Thanks for your explanation, it makes sense. However, I noticed something interesting: even measurements from the red target sometimes return a status of 255. After some testing, I discovered that the sharpness setting has a significant impact on the occurrence of status 255. When I set it lower than the default value of 5, the measurements become much more stable. Currently, I have it set as follows:

vl53l5cx_set_sharpener_percent(&dev, 1);

You mentioned, "But the zones in the middle are just lost." I didn’t fully understand this part. When I configure the matrix in 4x4 mode, I notice that measurements in zones 4–7 seem to align with where I need to target to detect the red ball, which is positioned near the lower end of the middle. Could you clarify what you mean by "lost zones"?

Additionally, I experimented with this setting to track a fast-moving ball:

vl53l5cx_set_ranging_frequency_hz(&dev, 200);

It seems I can go up to 200 Hz, but the datasheet mentions a maximum of 60 Hz. Why is there a discrepancy between the datasheet's stated limit and what I’m observing?

Looking forward to your insights!

Best regards,

[John E KVAM · Accepted solution]

When you place the sensor at the edge of the table like that, some of the zones that shine on the table at nearly a zero angle are going to be problematic. Some photons well return at nearly a zero distance, and some will see your red target. But the sensor kind of expects all of them to mostly come from a single place. So, the standard deviation of the result is going to be halfway between 0 and 120 with a standard deviation of 60 or so. The sensor doesn't know what to do and returns a 255 status. "just lost" was me saying the data was too diverse to get a number, and you get a 255 error status instead.

To get the accuracy numbers in the data sheet you are going to need a certain amount of integration time. At 60Hz we can meet the accuracy specification. You can go faster, but you will lose accuracy. But if you only need the 'ball / no ball" decision maybe favoring speed over accuracy is a fine idea.

- john