I have connected a lidar-lite v3 on raspberry pi 3 via I2C port.
I have wiring the sensor in accordance with the manual (with capacitor) (Lidar Red wire on Pin 2, Black on pin 6, Blue on pin 3, Green on pin 5, capacitor between 2 and 6)
With i2ctools and i2cdetect -y 1 command the lidar sensor is correctly detected on 0x62 register.
Now when I want to read any register I have always zero for answer except for the register 0x65 which return 0xFF.
I have try to write 0x80 to this register but I have the same answer 0xFF.
I have no communication fault and same comportment with i2sget command and python commands with smbus module.
Could you help me for this point.
What you describe really sounds like a power issue.
Please note that the LIDAR-Lite can require up-to 500 mA during initialization.
It is quite possible the RPi3 is not able to provide enough power and therefore the core of the device is unable to initialize properly.
We recommend that you try the sensor using a stable, 5 V DC alternative power source (that can provide 500 or more mA). This power source’s 5 V output would be connect only to the LIDAR-Lite. The GND should be common to the entire circuit.
Hi,
Thank you for your reply.
I have try with to different external power supplies, one at 1A one at 2A.
I have the same issue.
Do you think that my Lidar-lite is out of order ?
Best regards
Thank you for the detailed picture with annotations.
We notice in your wiring that the power supply used seems to be set to 4.5 V DC. Please note that this is the absolute minimum support according to the specifications and therefore may cause an issue. Would it be possible to test it with a power supply that has a nominal output of 5 V DC?
We discussed your issue with the manufacturer and here is what they had to say:
[/font][/highlight][/font]
[font=arial, sans-serif][highlight=#ffffff][font=Verdana, Arial, sans-serif, Tahoma]We recommend that you try this sensor with an Arduino and the official library, as mentioned by the manufacturer. This would allow us to test the sensor in a simple and known configuration to ensure there are no issues.[/font][/highlight][/font]
[font=arial, sans-serif][highlight=#ffffff][font=Verdana, Arial, sans-serif, Tahoma][/font][/highlight][/font]
[font=arial, sans-serif][highlight=#ffffff][font=Verdana, Arial, sans-serif, Tahoma]Other than that, please verify all the other information concerning I2C use with the RPi.[/font][/highlight][/font]
[font=arial, sans-serif][highlight=#ffffff][font=Verdana, Arial, sans-serif, Tahoma][/font][/highlight][/font]
[font=arial, sans-serif][highlight=#ffffff][font=Verdana, Arial, sans-serif, Tahoma]Sincerely,[/font][/highlight][/font]
[font=arial, sans-serif][highlight=#ffffff][font=Verdana, Arial, sans-serif, Tahoma][/font][/highlight][/font]
We received our Lidar Lite v3 module last week and I’ve encountered the same issue as described here:
0x01 register is zeroed out (so we have Health Flag in error state 0) and 0x65 toggles its state on each read (0xFF/0x00). Module draws 107mA and voltage is correct – 5V0.
Calling 0x00 (reset FPGA) on 0x00 register has no effect.
I checked Lidar Lite v3 with Rasbian 2016-11-25 and figured out what’s happening – due to upgraded kernel this change has been merged and now I2C interface always uses repeated start (though it should be enabled explicitly via I2C_RDWR ioctl call – Combined R/W transfer (one STOP only)).
I’ll reverse this patch on my machine, test it and try to fix this.
If the kernel upgrade causes the I2C driver to force repeated starts, then there is not much to be done to use the LIDAR-Lite v3 since it does not support repeated starts at this time.
Therefore, the two main options would be:
Use a previous kernel that does not have this issue (forced repeated starts). Older versions are available here.
Apply a kernel patch to this kernel to remove this issue.
We figure option #1 is the simplest for more people, as #2 requires quite a bit of more knowledge and work.
Third long-term option – they (engineers/manufacturers) should fix Lidars’ I2C chip in next iteration, as I2C protocol explicitly allows combined R/W. It’s in the spec (and it’s faster + mitigates clock stretching issues).
@krookdfinger I’ll try to dip my hands in this issue tomorrow. This needs to be fixed in kernel module.
it’s unbelievable look like there is no responsibility behind open source product, manufacturer don’t care about their product and Kerner has been updated and no one in the world can run their Lidar lite v3 on Raspberry Pi, I really appreciate if someone can resolve this issue