VL53L1X spurious readings when nothing is in range

[DavidEGrayson]

I have an application where I run the VL53L1X in lite ranging mode and short distance mode with a timing budget of 10 ms (100 Hz) as described in AN5263.

I recently noticed that on at least one unit (and probably more) the VL53L1X reports a spurious distance reading of 0 mm with no errors even though the sensor is pointing into an empty space and there are no objects within the 1.3 meter range of short distance mode.  This spurious reading happens about 10 times per minute, and the rest of the readings are regular expected errors.

I am not using the API (STSW-007) directly, but have implemented code that does the equivalent thing.

Here are some VL53L1X register values from these spurious readings:

1. The lower 5 bits of the VL53L1X result__range_status register (0x89) is always 9.  That corresponds to VL53L1_DEVICEERROR_RANGECOMPLETE and that is the value that the API maps to 0.
2. The result__stream_count register (0x8B) is between approximately 130 and 250.  
3. The result__final_crosstalk_corrected_range_mm_sd0 register (0x96:0x97) is always 0.
4. The result__dss_actual_effective_spads_sd0 register (0x8C:0x8D) is always 53992, which means 210.9 spads.
5. The result__peak_signal_count_rate_crosstalk_corrected_mcps_sd0 register (0x98:0x99) is between 200 and 450.  
6. The result__ambient_count_rate_mcps_sd0 register register is between 1000 and 1300.

Is it expected behavior for the VL53L1X to report a range_status of 9 and non-zero stream_count alongside an erroneous range?  Is there some additional error checking that I must do before trusting the range besides checking those two registers?  For example, maybe I need to filter out readings with low ranges and high SPAD counts.

If I change the timing budget to 20 ms, the problem seems to go away.

In case it helps, the identification_revision_id (0x111) register is 16 and ranging_core__revision_id (0x681:0x682) is 0.

[John_Kvam]

Well actually there is something in range - that's how you get photons returning. But it's not what you want. It's crosstalk and it comes from the coverglass you are using or there is some bit of structure that is returning photons. 

There are several ways to fix this.

One is to run the crosstalk calibration routine extract the numbers and re-insert them at every boot.

Or you can 'wing it' and only accept ranges that have a signal strength above the crosstalk amount. (This solution sounds easier, but all those zero-distance photon counts lower the average distance, and you end up under-ranging.)

Read the section of the user manual on crosstalk and it explains the solution.

Most people get away with doing the calibration of the first few units off the production line, and using that result for the entire production run. 

 - john

[DavidEGrayson]

Thanks for the help, John!

I should have mentioned I was not using any cover glass in the tests when I reproduced the spurious readings: I just had a bare VL53L1X on a PCB pointing into air at room temperature. The sensor also looked clean and the protective tape was removed. The VL53L1X datasheet only mentions doing crosstalk calibration when there is a cover glass, but that datasheet also says 50 Hz is the maximum ranging frequency. Since we are pushing the frequency to 100 Hz as described in AN5263, does that perhaps increase the sensitivity of the sensor to cross-talk caused by the sensor's package and make the calibration needed?

I might solve this by filtering out readings with a low distance and a high SPAD count, using the SPAD count as an inverse indication of the signal strength.

[Zhiyuan.Han]

Hi 

As John shared, if sensor detected a target, that means some photon was detected, and it's value above the valid threshold, the photon could come back from target, cover glass or background noise. and you have shared there is no target, no cover glass, so the last remining factor could be ambient noise. 

maybe you can try without any ambient light condition to check if it is the case. 

Br

Zhiyuan.Han