The VL53L1X outdoor performance is hindered by huge amounts of noise, and wildly fluctuating results, compared to indoors. I notice that the demos I can find online about this sensor conveniently never show it outdoors, although some articles mention it being used as a reversing sensor, or even a drone landing sensor...
Also, since this is supposedly the official Q&A place for ST devices, why is there such a dearth of answers here? A previous query regarding this outdoor problem received no satisfactory answer.
I found somebody asking about a filter, only to be told it's not a visible light sensor anyway.
Is it me, or is this sensor not meant for outdoor use? I'm only a hobbyist roboticist, and the simple code I've written so far works superbly indoors, but point this sensor towards daylight and all bets (and readings) are off.
Am I missing a code setting, or is there actually a filter that will solve this issue. I know I'm repeating questions asked before, but the lack of definitive answers is frustrating.
Sorry for the slow reply. This is entirely my fault. The email alerts were not getting to me.
But I should have checked anyway.
As you guessed, it's an indoor sensor. We didn't intend it that way, it's just physics.
The sensor outputs an eye-safe laser light. If you could see it, it would be about as bright as a common Red LED on must electronics.
Outdoors we go up against the sun. Which generates a ton of 940nm light. (Oddly, there is not as much 940nm as the visible frequencies, but still a lot.)
And all that light looks to the sensor like noise.
When the signal to noise ratio goes too low, we cannot get an answer.
The drone landing works because the sensor is pointed down - away from the sun.
You will also see the sensor works in the shade of a building.
But in sunlight, with any direct light we cannot give an answer.
Hi, I am an embedded developer.
It was mentioned that it was used as a reverse sensor or even a drone landing sensor, so I immediately tested it with Aduino.
The result was failure.
Modifying parameters inside short and long modes does not work in external natural light.
"ambient light 200 kcps/SPAD = Short 1300mm" within the data sheet
There's this part, but this is an inside story of an office with sunlight outside the window.
It's a signal to noise problem. The eye-safe laser is only about as bright as an indicator LED. In sun-light the SPADs get saturated with the sunlight and simply cannot 'see' the signal.
The sensor's light is 940nm and thus invisible. But the sun generates a huge amount of 940nm completely screwing up your results.
In modern buildings, low-e glass is used and that blocks an awful lot of non-visible light.
Your results show that your glass may be more toward the clear spectrum in the graph below.
We are looking at the issue, but the only solution appears to be a lot more SPADs (so they don't saturate). And of course that's expensive.
I am trying to better understand the meaning of configuration registers in VL53l1x to mitigate some problems. Do you know if there is any reference manual for VL53l1x that has some more detailed information? Resources available on ST site seem to be lacking the information. E.g. it would be beneficial for me to understand meaning of the following registers:
ST deliberately does not publish what this stuff does. Working at that level is a real pain - even we have trouble with it. Instead we published a couple of APIs. The APIs aren't amazingly easy to follow but they are tons better than dealing at the register level. The PERIOD A and B are the times between the small blasts of light. By making them shorter you get more 'pings' per millisecond, but you limit the range of the chip. So setting up for short, Medium and long affect these registers. The reason that A != B is to prevent radar aliasing - which you can google.
The use of TCXO in radio packages is for the tight on-frequency transmission, it narrows the general band which your radios occupy, and improves the receiver sensitivity because the transmitters are placing here with their energy where they're intended too, and the receiver is asking inside the right area