2022-09-14 12:43 AM
Hi,
I am using a VL53L1X sensor and using the LITE driver version 1.0.2. I am finding a condition where in a random situations the sensor is returning 0 in the range measurement while looking at a long distance <4m. This distance will continue returning the same value after reaching that condition.
After trying to change some of the configurations I discovered that the only way to recover the device is to switch from long distance mode to short distance mode, and back to long distance mode. My best guess is that at some point there was an unwrap status which was not recovered. Unfortunately I don't have good means to recover the status information from that code.
After taking a more detailed look at the LITE driver and Full driver documentation, I found that the later presents some other status not directly documented on the LITE driver. Nonetheless, in the cases of errors, I could not find good documentation on what would cause the status error, nor if there is any means to recover from them without rebooting the device.
Do you have any available documentation with better detail on what the status means, and actions that need to be taken, if any, when you run into error status? Thanks for the input.
2022-09-14 07:53 AM
The marketing of the device specifies the farthest distance on can range, but that 4M is a bit misleading.
It says the device can go to 4M if you are looking at a white target 2meters in diameter, with no ambient light (no sunlight).
But not all targets are large, flat, white targets. It could well be that you are simply not getting enough photons back from your target to be able to 'see' it. What happened when you brought your target back closer to the sensor? Did it start to be seen again.
You didn't say what status you were getting, so it's hard for me to tell what was going on.
In the ULD driver, one range is not very dependent on the prior range. We do take into account the signal strength of the prior range to adjust the number of SPADs we use, but as the target gets past a few feet, we should be using all the SPADs.
I'm going to guess that it was not your switching modes that fixed it, but perhap you changed some of the physical setup?
Thats all I can think of.
2022-09-14 08:10 AM
Hi John,
First thanks for the quick reply.
In general the measurement is performed in indoor conditions. Unfortunately I cannot give you exact conditions, but an office space with white LED lamps probably helps slightly to describe the condition.
When I moved a target closer to the sensor it did not respond. It kept reporting zeros. I have tried this with different objects, including a brown cardboard box if that helps a reference. Moving the object anywhere from 25mm to 1000mm did not change the range the returned distance value.
Nothing changed on the physical set up as far as I could tell. Before switching the distance range setting I tried changing other parameters e.g. the RoI and the measurement interval. In those cases I did not see the sensor getting out of the continued "0" output value. That is why I think having extra information regarding the meaning of the status parameters may be helpful.
As mentioned, unfortunately my current api lacks tracking information for the status as the information provided on the LITE driver, only mentioned the information as possible warnings. I will add some tracking information, but given that the event is a bit random to reproduce, I would like to have further in sights of ways to correct the behavior based on the status.
Thanks again for your comments,
2022-09-14 08:19 AM
Then I have to change my answer. Your sensor stopped ranging. When this happens again, see if you can find a laptop camera and look at the sensor. These cameras have a poor IR filter, and you will see the glow if it's ranging. (Can't use an Iphone - they have a great IR filter, and you will not see the glow.)
Best to test for a camera while the sensor is running. It's a bit tricky to see unless you get the camera in just the right spot.
So why did the sensor stop?
The most typical case is noise on the XShut pin. This pin is subject to noise and a little noise here will cause it to partially or fully reboot, and you end up with a sensor that is waiting for the start command.
Of course the power pin must be considered as well, but most people get that right. A bigger cap on the Xshut pin near the sensor generally does the trick. Bigger pull up might help as well. Shorter wires - if you are using it in a satellite configuration.