Lidar-Lite v3 return always zero with raspberry pi 3

scharette · June 15, 2017, 1:04pm

Hey,

Thanks for the good link on the upgrade/downgrade for the kernel. We are certain this will help users who are less knowledgeable about kernel downgrades (or even patching!) to be able to use their LIDAR-Lite v3 properly.

As for your other comments, I’m not too sure what to say. I have a feeling that the repeated start feature of the I2C specification, which was meant to allow a master in a multiple master setup to keep control over the bus, has started to be used by default as a way to save sending a stop condition in single master buses, too. While that is not wrong, it is possible for slaves to require a stop condition in some cases (and sometimes with good reason). This answer here is quite detailed about this. Here’s an excerpt of the answer:

As a matter of fact there was work I did, some years back, designing some slave devices into FPGA type parts. I found it essential to decode the stop condition and use that to reset the slave’s transaction state machine. The main reason for this is that strange things can happen on the bus, things that the master side of the bus didn’t even expect to happen. When an operation in progress gets corrupted by these “unexpected things” havoc can arise that takes some work to recover from. The best design strategy for devices is that they design to and utilize the stop sequence to produce the interface reset. When this strategy is followed the manufacturer of devices gets a lot less call for support and a happier batch of customers. Likewise the customer that is interfacing to devices will know about this and can simply provide for a “bus reset” of her/his I2C network that consists of a START -> STOP sequence pair. This can be utilized in the master side higher level driver software as part of a retry loop for when device communications has failed for one reason or another.

This is most likely the same design idea that went towards the LIDAR-Lite’s handling of I2C communications.

Concerning the kernel patch, well, if it really does force repeated starts (no matter what is requested) - which seems to be the case currently - it most likely needs to be reported as an issue and it can then be patched quickly.

The manufacturer most certainly care about their product, but these things do not change quickly or easily. It must be especially difficult to justify a design change (read: cost/time/effort) to fix something that is not broken and is instead an external issue (other entity’s products/code using repeated starts).

Sincerely,

taghvaei · June 16, 2017, 4:15am

Thanks Scharette for your descriptive comment, I’m actually new to this so I find that link really easy to use and I though it’s good to share with others.

craigbot · November 12, 2017, 3:39pm

Taghvaei rocks. I can confirm that this procedure worked on a SD card with the most recent version of Stretch. I have great sadness that I needed to lobotomize my kernel to get the Garmin to work, but great happiness that it is now working.

scharette · November 13, 2017, 12:25pm

Hi,

We are glad to have another confirmation that the procedure works.

As for patching the kernel, if you read the post above, you will notice this is a bug in the kernel code that was introduced recently: the code no longer allows you to choose between start/stop and repeated starts. It simply always uses repeated starts no matter what is asked.

So, you are in fact providing help to the kernel, not lobotomizing it!

Good luck with your project!

Sincerely,

z223i · March 31, 2018, 12:14am

Does anybody know how to git the version of the file just prior to November 27, 2016?

Have cloned the latest kernel . But, having troubles finding any version of the file other than the latest/head.

Tried using ‘git show’ for the file name but only see the head.

z223i · April 1, 2018, 4:26am

The person who changed the driver, Noralf Trønnes, suggested trying a device overlay and gave the following link:

github.com/raspberrypi/linux/bl … EADME#L699

Bruce

z223i · April 1, 2018, 3:59pm

The answer is…

Edit /boot/config.txt

Scroll to the bottom of the file.

Add the line:
dtoverlay=i2c_bcm2708

Save the file and reboot.

Done!

The change uses a different driver. It is the driver used in previous versions of Raspberry Pi.

scharette · April 2, 2018, 2:28pm

Hi Bruce!

Thanks for the info. That is some good news.

Sincerely,

z223i · April 3, 2018, 4:36pm

What happened to my post saying that this is now fixed.

It only requires an edit to a simple file.

z223i · April 3, 2018, 4:46pm

Built current version of Raspbian Stretch. It does work with the mod I mentioned above.

Bruce

scharette · April 3, 2018, 4:52pm

Hey Bruce,

Not sure what you mean. Would it be this post:

Otherwise, thanks again for confirming this. I am certain it will help many people in the future.

As a side note, the newer version of this product, the LLV3HP RB-Pli-17] will now support repeated starts.

Sincerely,

embring · May 13, 2018, 8:38pm

This overlay change in config.txt doesn’t seem to work on the latest Pi3 B+ and latest Raspian.
There are no BCM2708 chip any more, can the new chip handle the old i2c driver?
And if not, is it really possible to downgrade the kernel anymore?

scharette · May 14, 2018, 6:16pm

Good point concerning the BCM2708. We do not know about compatibility between the older driver

The best would be to contact the maintainer of the I2C driver for Raspbian and see with them what the best alternative would be (or if the drivers can simply work with start-command-stop properly and not always use repeated starts).

It should be mentioned that if code calls the drivers for I2C operations requesting no repeated starts (i.e.: full start-instructions-stop commands) and the drivers still uses repeated starts regardless, that should most likely be considered a bug of the drivers.

Not sure concerning kernel downgrades.

h3xxl · May 19, 2018, 8:13am

Here is my little test program working succesfully with Raspberry 3 B+

import sys
import smbus
import time

bus = smbus.SMBus(1)
LIDAR_ADR=0x62

def measure():
   bus.write_byte_data(LIDAR_ADR,0,4)

   bus.write_byte(LIDAR_ADR, 1)
   while bus.read_byte(LIDAR_ADR) & 1 != 0:
	  pass
	  
   bus.write_byte(LIDAR_ADR, 0xf)
   d=bus.read_byte(LIDAR_ADR)<<8
   bus.write_byte(LIDAR_ADR, 0x10)
   d|=bus.read_byte(LIDAR_ADR)
   
   return d

while True:
   t0=time.time()
   d=measure()
   t1=time.time()
   print "%3d %4d" % ((t1-t0)*1000,d)

scharette · May 22, 2018, 3:12pm

Hi,

Thanks for the piece of code! Glad to hear that seems sorted out!

Would you mind adding some details about what distro (and version) you are using and modifications (if any) that are relevant?

Sincerely,

h3xxl · May 25, 2018, 4:24pm

I’m using standard Raspbian Stretch. No modifications necessary. I2C must be switched on in raspi-config.

scharette · May 29, 2018, 1:52pm

Thank you for the details. All the better that it is a standard thing that can be used.
Good job!

embring · June 5, 2018, 9:40pm

@h3xxl

Very Nice!
Are you using Lidar Lite v3 HD or Lidar Lite v3?
I guess you are using Python, I’m not… I have to, maybe…
I have done some I2C code in Processing (Java) for various reasons, all other I2C devices works fine. Servo Drivers, Motor Drivers and IMU, but the Lidar only returns ZERO from all I2C registers. And the only possible reason I could find was the above…
Are you making som kind of workaround the repeated starts that the older Lidar Lite v3 (not HD) can’t handle?

Sincerely,

zoohe17 · July 5, 2018, 5:12pm

Hi

I am having the same problem with repeated as well. I have a RPi 3B+ with LLv3 sensor, and repeated starts seem to cause my sensor to malfunction.

@h3xxl Could you show me how you got yours to work?

Thanks

scharette · July 5, 2018, 5:31pm

The LLV3 (regular LIDAR Lite v3) does not work with repeated starts. It should probably be mentioned somewhere that this is normal according to the original specs of I2C (go look them up).

The LLV3HP (the newer, LIDAR Lite v3 High Performance) should accept repeated starts.