2025-08-26 2:21 PM
Hi all, it's me again. Close readers of this forum may remember I have a cluster of 5 VL53L4CX sensors that are attempting to range humans at an ideal distance of about 1.5-2m. I think I've successfully managed to avoid interference between the 5 sensors. I expect the data to be bit noisy from ambient light and moving humans, but I'm also trying to optimize, and starting to play with the huge number of Tuning Parameters available. I'm ok trading off latency for accuracy, especially at this long range.
A specifc question though:
some of my sensors are reporting a fair number of RangeStatus 4, 7, and sometimes 12.
4: VL53LX_RANGESTATUS_OUTOFBOUNDS_FAIL
Raised when range result is out of bounds
7: VL53LX_RANGESTATUS_WRAP_TARGET_FAIL
Wraparound occurred
12: VL53LX_RANGESTATUS_TARGET_PRESENT_LACK_OF_SIGNAL
Indicate that there is a target, but signal is too low to report ranging
I've finally got a setup that I can use to test tuning parameters, so I'm open to suggestions for optimizing my system.
Thanks, all, and especially @John_Kvam for your insights!
MGG
Solved! Go to Solution.
2025-08-31 8:38 AM
In the older sensors increasing the timing budget by 4x gave you 2x improvement in accuracy. But when the sensors started using histograms, that statistical model broke down. I expect you either have enough signal for a good measurement, or you do not.
Phasecal does help. A little. It means it takes longer go get started as the sensor spends longer calculating the clock phase, and it works but it's not magical. But it does mean that if you do a stop/start, your answers will be more consistent.
The trick to all this is that the longer you give the sensor to range, the better the answer. But that also means the sensor won't return as many values and thus the latency goes up.
The sensor gives a pretty good answer with a 30ms timing budget, but some people use 100ms for a 'better' answer.
However, if your target is moving, then this extra time is counter productive.
You have a huge advantage - you've read the documentation. This is not something most people do.
Increasing the merge threshold was put in so people could play with it. I don't think there is one magic setting that solves everyone's issues.
Best advice I can give is double it and see if you like it better. Do a binary search after that and narrow in on a good value.
- john
2025-08-27 10:29 AM
When using this technology, there is always going to be an edge between what can be detected and what is just outside of the detection area.
So the chip designers tried to give you a hint as to why the object was not detected.
Read this as 12 - Lack of Signal - I think there is something out there, but unless I get more signal, I can't be sure.
Or 4 and 7- there is something out there, but it's beyond my detection area.
As you are looking for stuff between 0 and 2 meters, I'd treat all these 'hints' as a no detect.
Hopefully you don't get any of them when there is actually a target in the area.
Although if you had a person at 2 meters that had only a small part of his body within the detection area, it could well be that you would get a 'low signal'.
If you were trying to dig something out at just the edge, adding more timing budget might help.
- john
2025-08-27 11:09 AM
Thanks a lot John. I'm finding that two of the five fairly consistently report some amount of 4 and 7, while the other three are not. They are also reporting 'good' findings among these messages. I do ignore the objects that report values other than 255 and zero, just trying to maximize the number of good readings.
If my timing budget is set to 45000, should it go higher? Can you offer a real-world sense of the latency vs. accuracy tradeoff or should I just try a bunch of different numbers on this?
Also, as per the user guide s5.3.2 and 5.3.2, I've set
VL53LX_TUNINGPARM_PHASECAL_PATCH_POWER
to 2, instead of the default of zero (are there other options that would be good for this?), and I've set
VL53LX_TUNINGPARM_RESET_MERGE_THRESHOLD
to 2500 ... (?). - the default there is 1500, and it says "If the user increases the value, the maximum ranging distance can be improved, but latency is impacted."... not clear by how much I should try to raise it? 100, 1000?
Really appreciate your insights.
2025-08-31 8:38 AM
In the older sensors increasing the timing budget by 4x gave you 2x improvement in accuracy. But when the sensors started using histograms, that statistical model broke down. I expect you either have enough signal for a good measurement, or you do not.
Phasecal does help. A little. It means it takes longer go get started as the sensor spends longer calculating the clock phase, and it works but it's not magical. But it does mean that if you do a stop/start, your answers will be more consistent.
The trick to all this is that the longer you give the sensor to range, the better the answer. But that also means the sensor won't return as many values and thus the latency goes up.
The sensor gives a pretty good answer with a 30ms timing budget, but some people use 100ms for a 'better' answer.
However, if your target is moving, then this extra time is counter productive.
You have a huge advantage - you've read the documentation. This is not something most people do.
Increasing the merge threshold was put in so people could play with it. I don't think there is one magic setting that solves everyone's issues.
Best advice I can give is double it and see if you like it better. Do a binary search after that and narrow in on a good value.
- john
2025-08-31 5:28 PM
LOL on RTFM. Thx John.