TOF Variable Results ( VL53L8CXV0GC)

[Vbala.1]

For the same setup the distance values jump between a very high and a very low value. 

Setup 1: unit facing an open space(ceiling) 

Result 1	Result 2	Result 3
2514, 2483, 2466, 2407,  2752, 2799, 2808,   15,     0,    0,    0,    0,     0,    0,    0,    0	2474, 2461, 2475, 3021,  2839,   16, 2808,   15,     0,    0,    0,    0,     0,    0,    0,    0	2502, 2461, 2451, 2455,  2858, 2766,   15,   15,     0,    0,    0,    0,     0,    0,    0,    0

TOF Sensor does not seem to perform well when pointing into an open space(ceiling). 

Setup 2: Limited Setup with box: 

Result 1	Result 2	Result 3
88,  105,   83,   74,   136,  136,  121,  122,    58,   43,   15,    0,     0,    0,    0,    0	87,  105,   84,   75,   137,  135,  120,  122,    59,   43,   15,    0,     0,    0,    0,    0	89,  106,   85,   74,   144,  136,  121,  122,    59,   43,   15,    0,     0,    0,    0,    0

Placing an object to limit the distance improves the reliability of the system. 

NOTE: The coverglass calibration(Xtalk) has not been performed. Please help us solve this issue in setup 1. 

[John_Kvam]

CHECK THE RANGE STATUS FIRST!

With this sensor, no target returns kind of an unpredictable range. The sensor only works if the sensor sees enough photons. The RangeStatus will tell you what is going on. 

The proper test is:

For each zone {

   If (number of targets >=1 AND the RangeStatus is either 5, 6 or 9) then you have a legit range value

   otherwise you have a random number. 

}

In your first examples, some of the zone are seeing enough photons - at 2.5 meters. But the other zone don't see enough to give a result. You can either be content that there is not target or you can increase the integration time, which will allow you to range farther. 

Either way, one MUST check both the number of targets and the RangeStatus before even looking at the range result.

- john

[Vbala.1]

As per your guidance, we have verified both the RangeStatus and NumberOfTargets before using the range data.

Our current handling of RangeStatus, based on the logic shared by your team, is as follows:

if ((status == 5U) || (status == 9U))
{
ret = 0U; /* ranging is OK */
}
else if (status == 0U)
{
ret = 255U; /* no update */
}
else
{
ret = status; /* return device status otherwise */
}

The output:

2250 : 0 2207 : 0 2202 : 0 2192 : 0 |

3139 : 0 2728 : 0 2729 : 0 2715 : 0 |

|

637 : 13 12 : 4 13 : 4 16 : 0 |

Based on our testing and observations, we would like clarification on the following points:

In your earlier explanation, RangeStatus values 5, 6, and 9 were mentioned as valid ranging cases. However, the provided logic treats only 5 and 9 as success cases. We also observe that RangeStatus = 6 is returned intermittently. Could you please confirm whether status 6 should also be considered a valid ranging result?

We observe that NumberOfTargets is sometimes returned as 0. Could you please clarify what this indicates? Does it mean that no valid target was detected in that zone?

In some scenarios, we receive RangeStatus values of 4 or 13. Could you please clarify what these values represent and whether the associated range data should be treated as invalid?

In 4×4 resolution mode, we observe that the 3rd row (all four zones) consistently reports NumberOfTargets = 0 when focusing on long-distance targets. This behavior is not observed at shorter distances. Could you please explain the reason for this behavior and whether it is expected?

Could you also share the complete definition or reference table for all possible RangeStatus values, along with the recommended handling for each?

- Vikaash

[John_Kvam]

There is a lot there so I'm going to try to get them all - but perhaps out of order. 

First - Range Status 6 is valid - sort of. It only happens on the very first range after a start, but it takes two ranges to be absolutely certain that you don't have an aliasing issue (Target beyond the 4M max incorrectly reported as a near target.)

If you don't actually have a target within the 4M, or your target is of such a low reflectivity it does not return enough photons, you simply get 0 targets in that region. Sometimes you can get some photons, but not enough for a really good estimate, then you will get a status 4 or 13. 

And do check the number of targets. The buffer is NOT cleared and stale IS in the buffer if no target is seen. 

(This stale data drives me crazy, but not clearing that buffer saves time and power. And the chip designers did not ask me my opinion. :)

The logic should be:

For each region, if there is at least one target and that target's RangeStatus is valid, then you have a good distance. 

As for your '4th row', a 'no target' means there was no valid target within 4M. 

Note that the sensor can detect a white sheet of paper at 4 meters, but a dark black sheet of paper can probably only be seen to a couple of meters. So the target might be there - but the sensor cannot see it.

Remember, unless you get at least 0.5 million reflected photons per second, you will not 'see' the target.