VL53L1X ULD short range behaviour when target is located outside of measurement range

[mf101]

We are using the VL53L1X sensor with the ULD API in one of our products. During final evaluation we encountered situations where the sensor delivers wrong measurement values with status OK.

In the attachment you will find the documentation of measurement series which were performed using a white wall with even surface covering the full FOV of the sensor (target is larger than 1.5x1.5m) within the range of 4m. The measurement setup is in a cellar room without ambient light and only room lighting (low IR).

Timing budget and inter-measurement time were both set to 15ms and short range distance mode was selected. In the attached Excel sheets you will find min/max values for distance value, ambient and counter values for the different status values (e.g. number of results flagged with status 4 -> cnt4). We call these statistical values and can read them / reset them via commands sent to our product.

The measurement was performed as follows:

1.      Position our product at the distance „d“

2.      Reset the statistical values

3.      Let the sensor measure for 5s

4.      Read out the statistical values and fill them in the Excel sheet

5.      Increment „d“ by 100mm and start again from 1.

When you look at the results (VL53L1X_ULD_tb15ms_short_range.xlsx), you will see that up to a distance of 1.4m the sensor measures fine and all results are marked as OK (all counters except cnt0 are zero -> no errors).

Between 1.4m and 2.1m all results are marked as “out of bounds�? (all counters except cnt4 are zero), which is expected, as we exceed the maximum range.

Beginning from 2.2m we see a massive increase of incoming measurement results which are marked as OK, but the distance value is completely wrong (see minVal, maxVal).

Especially distances between 2.3-2.5m are affected.

After this measurement we increased the timing budget / inter-measurement time to 20ms and found out that this greatly reduced the effect (see VL53L1X_ULD_tb20ms_short_range.xlsx), yet at 2.3m a minor amount of results were marked as valid again.

In our application scenarios most of the time the sensor will see a target within the measurement range, but it is not guarenteed and we rely on the sensor marking such measurements as invalid. Under no circumstance we can accept wrong distance values marked as valid. It would be fine if the sensor reliably marks them as "out of bounds" or "wrap around".

Since of the unreliable measurement results we are unable to release our product. How can we get rid of this issue to ensure a reliable sensor operation ?

[John E KVAM]

Switch to long mode.

You are running afoul of something called Radar Aliasing (Google it). The light flash (or Ping) being sent out at time N is being received AFTER the ping from time N+1. The sensor assumes the return signal is from the most recent ping. In short mode we get good values up to 1.2M and can detect aliasing up to 2.4M. But past 2.4 we cannot detect the aliasing and you will get values starting over at zero. If you want to prove this, use a large mirror or some retro-reflective tape. It will return more photons than your white wall, and the effect will be much more obvious.

In long mode we seperate the pulses by a longer time. Thus the aliasing shows up at a much greater distance. But with that spacing there are fewer pings, and thus less signal. You will need a longer timing budget to get enough signal to make a good measurement in long mode.

(There is also a Medium mode that might solve your wrap issue and still allow the reqired timing budget.)

if you cannot solve your issue with long mode, then the next step would go to the VL53L1CB. (Identical part shape and function.) But the CB pulls the raw data from the sensor and processes it in your host with the software we provide. This code is much larger than the ULD, but it extends the wrap point to 8M.

And although the code is much larger, the calling interface is remarkably close to what you have, so if you have the MCU memory, it should be able to fit right in.