cancel
Showing results for 
Search instead for 
Did you mean: 

Distance Measurement Using VL53L4CD - Range Measurement Update Delay

Brian_Azzopardi
Associate II

Hello all,

We are once again using one of the VL53 TOF sensors for a close-proximity ranging application. For this application we are using code from the VL53L4CD_ULD_Driver.

After initialising the system using the VL53L4CD_SensorInit function, we are obtaining single measurements by starting the sensor via VL53L4CD_StartRanging and getting results via get_data_by_interrupt()

We are noticing that if the target distance is changed, the first 2 or 3 measurements after the target distance change, are incorrect (look like values from the previous target distance). The 3rd or 4th measurement (and onwards) are correct. Please have a look at the below log:

 

--------------------------------------------------------------------------------------------------------------------------------------

bVL53L4CD ULD ready ! - VL53L4CD INITIALISED

TARGET PLACED ~85MM FROM SENSOR AND STARTED GETTING SINGLE MEASUREMENTS

eStatus =  0, Distance =  86 mm, Signal =  832 kcps/spad

eStatus =  0, Distance =  87 mm, Signal =  848 kcps/spad

eStatus =  0, Distance =  86 mm, Signal =  857 kcps/spad

eStatus =  0, Distance =  87 mm, Signal =  869 kcps/spad

eStatus =  0, Distance =  86 mm, Signal =  868 kcps/spad

eStatus =  0, Distance =  86 mm, Signal =  877 kcps/spad

eStatus =  0, Distance =  86 mm, Signal =  865 kcps/spad

eStatus =  0, Distance =  86 mm, Signal =  869 kcps/spad

eStatus =  0, Distance =  87 mm, Signal =  869 kcps/spad

eStatus =  0, Distance =  87 mm, Signal =  881 kcps/spad

eStatus =  0, Distance =  87 mm, Signal =  861 kcps/spad

eStatus =  0, Distance =  84 mm, Signal =  870 kcps/spad

eStatus =  0, Distance =  86 mm, Signal =  864 kcps/spad

TARGET MOVED TO ~45MM FROM SENSOR AND STARTED GETTING SINGLE MEASUREMENTS

eStatus =  0, Distance =  88 mm, Signal =  866 kcps/spad - STILL MEASURING 85MM!

eStatus =  0, Distance =  86 mm, Signal =  854 kcps/spad - STILL MEASURING 85MM!

eStatus =  0, Distance =  43 mm, Signal =  4154 kcps/spad - FROM NOW ONWARDS OKAY AGAIN

eStatus =  0, Distance =  45 mm, Signal =  6408 kcps/spad

eStatus =  0, Distance =  44 mm, Signal =  6408 kcps/spad

eStatus =  0, Distance =  46 mm, Signal =  6424 kcps/spad

eStatus =  0, Distance =  47 mm, Signal =  6376 kcps/spad

eStatus =  0, Distance =  45 mm, Signal =  6344 kcps/spad

eStatus =  0, Distance =  46 mm, Signal =  6360 kcps/spad

eStatus =  0, Distance =  46 mm, Signal =  6416 kcps/spad

--------------------------------------------------------------------------------------------------------------------------------------

 

Any suggestions for solving this would be greatly appreciated.

Thanks in advance for your help!

 

Brian

Brian

RSO (RDI) at the University of Malta Department of Electronic Systems Engineering
1 ACCEPTED SOLUTION

Accepted Solutions
John E KVAM
ST Employee

The sensor does not have much memory. The range is taken, and the data is moved into dual-port memory so the I2C interface can get to it. Then the interrupt is triggered, and the next range starts. 

There is no way 2 ranges can be buffered up. 

I'm going to guess that if you put a time stamp on your ranges that you find you don't get the timing you expect. 

Sometimes people read the prior result twice - but in your case the signal strengths are different, and that means you are in fact reading different ranges. 

Somehow your code is buffered. 

But if you put a timestamp on the data as soon as you get the interrupt, you will figure out what is going on.

(This has happened to me too.) 

Perhaps your stop was issued after the range was taken - and you are reading stale data there. But that would only account for one stale range, not two. 

There is an interrupt immediately after doing the start. I'd clear that one without reading any data. The next one would be valid.

- john


If this or any post solves your issue, please mark them as 'Accept as Solution' It really helps. And if you notice anything wrong do not hesitate to 'Report Inappropriate Content'. Someone will review it.

View solution in original post

2 REPLIES 2
John E KVAM
ST Employee

The sensor does not have much memory. The range is taken, and the data is moved into dual-port memory so the I2C interface can get to it. Then the interrupt is triggered, and the next range starts. 

There is no way 2 ranges can be buffered up. 

I'm going to guess that if you put a time stamp on your ranges that you find you don't get the timing you expect. 

Sometimes people read the prior result twice - but in your case the signal strengths are different, and that means you are in fact reading different ranges. 

Somehow your code is buffered. 

But if you put a timestamp on the data as soon as you get the interrupt, you will figure out what is going on.

(This has happened to me too.) 

Perhaps your stop was issued after the range was taken - and you are reading stale data there. But that would only account for one stale range, not two. 

There is an interrupt immediately after doing the start. I'd clear that one without reading any data. The next one would be valid.

- john


If this or any post solves your issue, please mark them as 'Accept as Solution' It really helps. And if you notice anything wrong do not hesitate to 'Report Inappropriate Content'. Someone will review it.

Hi John,

 

Thanks for replying. I will follow your suggestions and post any updates I may have.

 

Brian

RSO (RDI) at the University of Malta Department of Electronic Systems Engineering