Ranging time multiplied by 2 when a target is in front of sensor (VL53L4CX)

[CMacq.1]

Hello,

I noticed a difference of ranging time on VL53L4CX in function of target presence or not.

My parameters : AVG = 3 ; DTIM = 33 ms ; INTERMEASUREMENT = 100ms

Current measurements :

• Without target : pulse width = 38 ms ≈ DTIM

• With target : pulse width = 69 ms ≈ 2 x DTIM

Can you give me an explanation for that please.

Thank you in advance.

Clément Macquet

[Zhiyuan.Han]

Hi Clement

I think there should be something wrong about your setting, as L4CX is working in continuous mode, so it should not have INTERMEASUREMENT parameters.

Below are some link which may help you.

Datasheet link:

Datasheet - VL53L4CX - Time-of-Flight sensor with extended range measurement (st.com)

User manual link:

A guide to using the VL53L4CX Time-of-Flight sensor with extended distance measurement - User manual

API link:

STSW-IMG029 - VL53L4CX Time-of-Flight sensor with extended range measurement application programming interface (API) - STMicroelectronics

Br

Zhiyuan.Han​

[au.jacquot]

Hi Zhiyuan,

I am working on the subject with Clement.

As he said, our problem is the ranging time twice as high when a target is present.

Our device periodically takes 3 measures and then stops. (UM2931 section 2.3)

The following functions are called :

1- VL53LX_StartMeasurement

2- Wait for a result (we tried polling register or monitoring IT pin state)

3- VL53LX_GetMultiRangingData

4- Repeat 3 times steps 2/3

5- VL53LX_StopMeasurement

The sensor should operate as explained in the user manual (UM2931) page 8 figure 8, one measure (timing budget) per Inter-measurement. 

But, when a target is present, the measured timing budget is twice (69ms) the configured value (33ms, measured 38ms). The current consumption of the sensor is therefore twice as high.

Do you have an explantation about that ? We use the driver's api version v1.2.0.0 (2021)

Thanks for your help

Aurélien

[Zhiyuan.Han]

Hi Aurélien

The UM2931 is for VL53L4CD, but for the code you provided, it seems come from VL53L4CX, so please identify which sensor you are using?

 

 

VL53L4CD - Time-of-Flight (ToF) high accuracy proximity sensor - STMicroelectronics

VL53L4CX - Time-of-Flight (ToF) sensor with extended range measurement - STMicroelectronics

I did a test with my board, the 1st column is the frame time in ms, by default timing budget is 33ms and plus few ms processing time, aligned with the expectation, can you show me you logs or how can reproduce your issue? 

 

 

Br

Zhiyuan.Han

[John E KVAM]

this is a tricky one. 

When one does a range, there is a possiblilty of something called radar aliasing, or 'wrap around'. It's where a target is beyond the max range of the device and the returning photons get associated with the wrong output flash. If the max range is 4M, a target at 4.3 meters could show up as a target at 0.3 meters. 

To detect this, the sensor does 2 sub ranges - call them A and B. Say the max range of the A timeing is 4M and the max range of the B range is 4.2. That target at 4.3 would show up as a target at 0.3 for the A range and 0.1 for the B range. It's enough to know we have an issue and set the Wrap Around status return. 

If you are running continously, we can return a result after each sub-range, knowing the prior or next range can do the wrap check. 

If you are running Autonomously and there is a gap between ranges, we cannot assume an B range will immediately follow the A range. This means we have to do the A and the B before we return a result.

So when running continously the answer is return at the end of each TimingBudget. When running autonomously the answer is returned after 2X the timing budget. 

And that is whay you are seeing.

- john