Tof Sensor Light intensity

[PVala.1]

Hi,

We are using Tof Sensor VL53L1X in our project.

Following are the queries regarding light intensity while measuring distance .

1. 1. Dark light means what lumens you consider the light intensity
2. 2. If any room is with 1000 lux light intensity than what is the maximum distance can we get ?
3. Is there any relation between light intensity & kcps /spad
4. What light intensity you have considered when Ambient light consider to test the range.

[John E KVAM]

One thing to understand is the sensor only cares about 940nm light. You could light up a room with several thousand LED lights and it's still 'dark' to the sensor.

However holigen lights do emit 940nm light as does the Sun.

So a good bunch of Sunlight coming through a window will affect the overall ranging distance.

In a bright California summer day outdoors - generally described as 100K Lux, you can range maybe a foot or two. It is very dependent on the target, and the sensor's relationship to the sun.

Lux as a measure really doesn't take into account invisible light frequencies, but has meaning in Sunlight. Given a lux number, we can estimate the 940nm light intensity. But at 1K lux what the sensor does at 1K Lux is hard to tell. It's too dependent on the relationship between the sun, the target and the sensor.

Unfortunately you have to buy the evaluation kit and decide if the sensor will work for you.

But generally we sell the sensor as an 'indoor' device.

You can download the datatsheet of the VL53L1CB - our latest sensor. It has the expected distances at 1K lux. The CB version of the chip is physically identical, but runs different software. The software is more complex, but it does better. The announcement of the CB is supposed to be Mid October.

There is a relationship between light intensity and KCPS/SPAD. But it shows up as ambient light. (After a range you can ask the chip for this.)

In the signal strengh we return we subtract the ambient before we give you the signal strength.

This is done by taking an ambient ligth measure just prior to the range. Any signal we get over ambient is 'our' and we get the range from that.

If the ambient is too high and it saturates our photon detectors, of course we cannot identify the signal.

• john

[PVala.1]

Hi John,

Thanks for your response.

We want to know , is there any firmware change required in host if we need to use new chipset VL53L1CB instead of VL53L1X ?

[John E KVAM]

Yes. The processing of the data in the X version is done on the chip. Your MCU can be completely asleep waiting for an interrupt. ON the CB version the raw data is captured by the sensor and sent to your MCU. It is your MCU that gathers the data, and produces the answer. So yes, how they work is fundimentally different. The CB code we give you is larger, but not by an awful amount. And you must handle the interrupt (or be polling), get the data, and free the sensor to continue.

But this does have advantages if you want the best answer possible.

IN the next software release for instance we are almost doubling the detection range. All done by changing the processing in your MCU. This would have never been possible if we did the work on the sensor.

-john

[PVala.1]

Hi John,

Thanks for quick response.

Following are some more queries as we are working on development on this:

1) Do you have data related to ToF evaluation. Measurement data (xls, csv) of distance measured from ToF ranging vs. actual target distance under different ambient lighting

2) Need to understand the power consumption of the ToF VL53L1X part configured with different settings parameters e.g. Timing Budget = 50msec , Inter-measurement Period = 500 msec. 

   As we need to configure Timing budget and Inter measurement period based on the power consumption , we need to understand the device power consumption for all the supported range of the    Timing budget and inter-measurement period . 

3) Also currently we have STM32F411 Series NUCLEO-F411RE board and ToF X-NUCLEO-VL531A expansion board . We need to use the VL53L1X_GUI PC based GUI software to perform some validation of ToF on the above NUCLEO board . But currently the VL53L1X_GUI PC based GUI software does not support for STM32F411 Series NUCLEO-F411RE board.

Can you provide binary image for STM32F411 Series NUCLEO-F411RE board which can flashed on the board and which allow to communicate with VL53L1X_GUI PC based GUI software and perform validation of ToF.

[John E KVAM]

not quite in order, but...

Power consumption can be estimated by assuming 20mA when the device is ranging and 0 when it is not. (neither of these numbers are exact, but they are close enough until you get serious.)

So 20mA * TimingBudet * number of ranges per second = power consumed.

I have one customer who ranges for 30ms, twice per second.

His consumption would be 20mA *0.030 * 2 = 1.2mA

I'm sorry about not supporting the F411RE, but it's not possible to support them all. The Nucleo-F401RE is not very expensive. Better in this case to just buy one.

As for the ambient lighting conditions, I only have what is in the datasheet.

if you are worried about ambient light, I'm afraid you are going to have to do the testing.

lighting is just too complex a problem to provide a simple table.

But i will admit that ambient light is our biggest challange.

[PVala.1]

Hi John,

We have procured evolution board for Tof and performed some experiments to achieve range and tof :

Can you please help us on following ?

Testing Setup :

      a) Lighting Conditions : Office Indoor Lighting

      b) Maximum Distance used for testing : 400mm

      c) Configured FOV : Full 16 x 16 SPAD array ( 27 degree )

      d) FOV 0 degree or center line : From the Centre of the SPAD receiver

     Observations :

      1. ToF Sensor supporting FOV consistently around 17.5 to 18 degree over below distances

            a) 100 mm , b) 200 mm , c) 300 mm ( These distances are selected for validation purpose )

   Setup Image :Please find the attachment for the validation setup image . (01_ToF_FOV_Validation_Setup .jpg)

2) What's shall be the difference in FOV and accuracy support if we use factory calibrated settings i.e. default calibration from ST, as the above testing is carried out based on factory calibrated device .

3) Detail procedure & setup on the calibration to be carried out at production line for calibrating the ToF Sensor . 

4) Any need of calibration we are using ToF just for coarse proximity sensing and not accurate distance calculation . 

[John E KVAM]

unfortunately I don't see the attachment, but here are my thoughts.

1) the diagonal of the FoV is 27 degrees, but we have a 16x16 SPAD array - so 19 degrees horizontal is right. Now if 1 micron of your target were to enter the field of view, I could not get enought of a signal to 'see' anything. So a bit more of your target is required. Once a few mm of the target is in the FoV, I can give an answer. So your 17.5 to 18 degrees sounds right. Using a highly reflective target will change this angle. Likewise a dull target will decrease the angle.

The offset and crosstalk will not really affect the angle, only the distance reading

The calibration details are in the datasheet and the user manual supplied with the API.

Calibration for offset is easy. Just put a 88% (white printer paper) at 140mm, and call the funciton - It does 50 ranges to insure reasonable temp, then averages the next 50 ranges. The difference between that average and the actuall distance is your offset.

Crosstalk is far more trick. You have to find a relitively dull target (17%) and find a distance at which you under-range by 20%. This takes a lot of experimentation. And the target has to be at least 1/2 the distance to the target in diameter. (At 1M, the target will have to be 0.5M in diameter.)

If you are only looking for when the target enters the FoV and not for accurate distance, you probably can skip the calibration altogether.

one note: if you have the VL53L1 Eval kit. Use the controls on the right hand side to narrow the FoV. You can go as low as 5 degrees.

And you might even consider a FoV 1 SPAD high by 16 tall. That actually might give you a better answer.

Do give it a try.

• good luck
• John

[PVala.1]

Hi John,

Thanks for your quick response as we are in development phase.

We have some more queries on this:

1. Availability of the ToF part - VL53L5

2. Need to understand options to increase the current FOV of the TOF sensor by additional system e.g. by addition lens to increase current ToF's FOV .

3. ToF is providing interrupt for every measurement time interval even it is configured with below settings . Please provide support on the same .

   Threshold Mode Configuration:

      DistanceMode: VL53L1_DISTANCEMODE_LONG

      TimingBudget: 50000 usec

      MeasurementPeriod: 500 msec

      IntrNoTarget: 0

      DetectionMode: VL53L1_DETECTION_DISTANCE_ONLY

      CrossMode: VL53L1_THRESHOLD_CROSSED_LOW

      Distance.High = 0

      Distance.Low = 1000 mm

   Preset Mode : VL53L1_PRESETMODE_LOWPOWER_AUTONOMOUS

    Expected or our requirement : 

   1) MCU / Host configures the ToF sensor to generate an interrupt if the any object within the 1000 m of FOV .

  2) MCU / Host enters into sleep mode by enabling interrupt as MCU wake-up source 

  3) If any object within the configured FOV i.e. 1000m of ToF , ToF sensor shall raise interrupt for the same . 

  4) MCU shall wake-up from sleep mode based on ToF based interrupt 

  Current Observation :

  1) We are getting interrupt for every configured measurement interval .

[John E KVAM]

The L5 is slated to be ROMed in April. Right now the sensor's firmware has to be loaded at bootup and that takes a lot of time and memory that small projects cannot afford. But we are using this time to make dead sure that the chip is as easy to use as possible. And some very large early adopters are willing to help in this regard.

To be honest I don't wouldn't count on seeing the part in the larger market until the June timeframe. It takes rather longer than one would have thought to build the demo boards, finalize he documentation, and create enough sample code that people can use it without a lot of handholding.

if you are getting interrupts even though there are no targets within 1M, then either the interrupt is not configured properly, or the system thinks there is a target.

What are the results of the ranging you are getting? Does it show a target when there really is not one? That can happen with too much crosstalk.

Try a simpler case. Put a large target at say a foot (30cm) . and then set the interrupt to 10cm. Do you still get the interrupt? With everything moved closer, you take the possibility of a bad range out of the equation. If your interrupt goes away, then it's a physical problem with your coverglass perhaps.

If the problem does not go away, then the setup of the interrupt is somehow flawed. Read the documentation and be sure you have what you think is right. Then try reversing the Inside, outside, below and above settings. I never liked the way those worked. They are not intuitive even after thinking about it. So, try swapping those settings.

And I got my first report of a bug in the driver the other day- so I'm not going to say that the interrupt function call is perfect.

• john