2024-11-05 03:49 AM
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
Solved! Go to Solution.
2024-11-05 06:59 AM
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
2024-11-05 06:59 AM
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
2024-11-12 06:05 AM - edited 2024-11-12 06:05 AM
Hi John,
Thanks for replying. I will follow your suggestions and post any updates I may have.