Problem with Lidar Lite v3

***** Related to this topic *****

I also wanted to add comment about the V3 accuracy at short range.
I am using the different Lidar Lite devices for about 3 years. and I got new devices a month ago that has the 2018/04 date on them.
For strange reason they behaves different at short range. At ranges less then 30cm the readings are very unstable, while they used be be stable at all working ranges on the past.
Attached link to video that I have compared two devices.
Top Plot is Lidar from 2016/09
Bottom plot is the 2018/04
the Scope has been configured to show persist reading of 2 seconeds and you can see the noise on the bottom plot, where the 2018/04 is attached.

What has been changed???

That been tested on at leat 5 “2018/04” and 3 older Lidars.
Also tested on different surfaces, that behaves differently …


Well, all LIDAR-Lite have issues with measurement readings at very short distances since they have optics configured for mid-long range distance measurements (typical distances are in meters).

As you may realize, without a more complex assembly, one set of lenses cannot be both good for very short distances (i.e. < 50 cm) and also long distances (up to 40 m).

It is possible that some minor improvements to long range distance measurements in the signal processing or optics have made the very short distances worse off.

It is very likely the processing chip and algorithm have changed since the first V3 model was shipped in 2016, but all of this kind of info is proprietary, so your guess is as good as ours.


@scharette Thanks for the replay.
In my case i need the short range values, more than the longer range.
btw I also have newer lidars than 2016, I have 2017 lidars that don’t have the issue.
Can’t we get from Garmin the product changes that might lead to that behavior change?


We’ve contacted Garmin to request more information about this and we’ll post here again once we have an update.

If you are more interested in short distances, you may want to consider the following instead:

]RB-Pol-332; 0-10 cm/:m]
]RB-Pol-455; up to 2 m/:m]
]RB-Pol-633; up to 4-400 cm/:m]


@scharette thanks again.
I actually need both short and long ranges, short is more critical and need to be accurate . the longer is more to avoid hitting the ground while descending wiht the drone and can be less accurate (its AGL Above Ground Level).
The range finder you advised look great, I will check them too, but still need the longer range Lidar too.

I’d recommend using both, then! http://https//
You can never have too many sensors*! http://https//

Here are some notes concerning the LL3 from the manufacturer:

We hope those extra details help!


*: OK, totally not true… but still… you get the idea :wink:

Its helps on some way, saying that the lidars has not been changed.
That is strange… like i Sayed it happens in at least 6 out of 6 sensors I tested (from batch of 20…)
I will ask my supplier to replace my batch, maybe the other batch will be “as before” if it won’t i will probably stop using that sensor…

You may want to try the attenuator or filter trick on the receiver part, though. The goal would be to effectively reduce the signal strength to a level where non-linearity no longer happens. Of course, that would most likely reduce the maximum range.

I try not to change the device, as you say it may lead to other side effects.
I basically try to understand what has been changed, is that hardware change? or firmware?
In order to check that I have saved the registers from the devices. i found differences on registers that probably should be different (readings) and found differances on registers that I don’t know what they are, because they are not documented.

I did notice that registeres 41 (H=W ver) and 4f (SW Ver) are equal (I got the register number from some github repo, because they are not documented too)
This is partial list of the registers: (Is there a way to attach full file?)
[table] [tr][td]Reg[/td] [td][/td] [td][/td] [td][/td][/tr] [tr][td]41[/td] [td]15[/td] [td]15[/td] [td]HW Version[/td][/tr] [tr][td]42[/td] [td]b5[/td] [td]bb[/td] [td]N/A - Note There is diff here![/td][/tr] [tr][td]43[/td] [td]6a[/td] [td]6a[/td] [td]N/A[/td][/tr] [tr][td]44[/td] [td]6a[/td] [td]6a[/td] [td]N/A[/td][/tr] [tr][td]45[/td] [td]14[/td] [td]14[/td] [td]MEASURE_DELAY[/td][/tr] [tr][td]46[/td] [td]14[/td] [td]14[/td] [td]N/A[/td][/tr] [tr][td]47[/td] [td]14[/td] [td]14[/td] [td]N/A[/td][/tr] [tr][td]48[/td] [td]0f[/td] [td]0f[/td] [td]N/A[/td][/tr] [tr][td]49[/td] [td]92[/td] [td]68[/td] [td]N/A[/td][/tr] [tr][td]4a[/td] [td]60[/td] [td]65[/td] [td]N/A[/td][/tr] [tr][td]4b[/td] [td]10[/td] [td]10[/td] [td]N/A[/td][/tr] [tr][td]4c[/td] [td]0[/td] [td]44[/td] [td]PEAK_BCK[/td][/tr] [tr][td]4d[/td] [td]80[/td] [td]80[/td] [td]N/A[/td][/tr] [tr][td]4e[/td] [td]26[/td] [td]26[/td] [td]N/A[/td][/tr] [tr][td]4f[/td] [td]2[/td] [td]2[/td] [td]SW_Version[/td][/tr] [tr][td]50[/td] [td]2[/td] [td]2[/td] [td]N/A[/td][/tr] [tr][td]51[/td] [td]71[/td] [td]71[/td] [td]N/A[/td][/tr][/table]

See attached image for attachments! :slight_smile:

Now Attached the full register list
Lidar Registers.txt (1.75 KB)

I am wondering if the issue exist on the HP version. but I don’t have one to check that

Interesting list!
That being said, it most likely won’t do either of us any good and here’s why:

I can also confirm from our own tests of all the different versions that very short distances will not be reliable. From the information we have available at this time, it really just seems like the non-linear results at very short distances are very much tied to randomness in the various manufacturing processes and will never lead valuable data between batches and therefore should be considered useless.

Of course, you could always map out the results for one sensor against various surfaces and situations, but that seems like a lot of work for data that will be sub-par. We strongly recommend instead using two sensors for your use case: one for short ranges (ex: 4-400 cm, like the RB-Pol-633) and the LIDAR-Lite for the longer ranges.


Hi Sébastien,
The issue is that we need the lidar (and used it, so far) between the ranges of 30cm-30m.
The non-linearity is less critical for us.

If that is the case, then the LLV3HP (RB-Pli-17) might be a better fit for you.
It still has non-linearity issues < 30 cm (signal strength too strong :stuck_out_tongue:), but it performs much better and typically provides data that is offset in only one direction when at very short ranges (instead of all over the place like the regular LLV3).

Is there new info about the issue?
Does anyone tried the HP vs the regular version?

Hi Sébastien,
I got an HP Lidar -
Final raw, the HP version doesn’t looks good, even worse in many levels:

• There is still noise in ranges between 10cm to 30cm.
• Even in 50cm reading seems noisier
• For unknown reason there is “pulse” of ~1V for ~50uSec after the PWM pulse. Its on every reading. (I am nut sure how to add picture of that)
• The behavior of the sensor on very close reading has changed. (SCR06) C1 is the HP, C2 is 2018/04 version and C3 is older version Lidar. I am not sure what my Flight control logic will do in that change of behavior.

Do you know if there are more complaints about the Lidar behaviors from other costumers?


Actually, you seem to be the only one we are aware of that has such issues at this point in time. Considering the quantity that we sale of these regularly, it would seem like your situation is unique. That being said, most of our customers seem to use the I2C interface, which is far more reliable especially at long distances, where the pulse length becomes quite long.

Here are details from the manufacturer:

In short, the sensor works best above 1 m and the main recommendation is that you should use I2C for more reliable data.