Do you have anything else connected to the EZ-B? 200mh is not nearly enough amperage for the EZ-B and it is probably browning out. If you have any servos, that is definitely the case.

Alan

Hey Alan,

Great suggestion. But just replaced previous power supply with a 12v 1A wall wart, ran the above code and erred after 200 samples with the red light coming on non-flashing and the board disconnecting from the wifi. Same as with the previous power supply.

This and my prior tests did not have anything else plugged in.

I suspect the 12V 1Amp supply would be fine without anything else plugged into the board? No camera, no servos absolutely nothing but the Lidar Lite.

Much appreciated,

Bill

I need to get in contact with Pulsed Light, I have seen the same thing. It seems like the sensor has a timeout on the I2C communication causing the issue. There's a few others having this issue that I've seen on the web. I believe they may have to give us a firmware update.

Thanks Jeremie,

I've did some more sleuthing and found LIDAR Lite works on 3.3V so I've started powering it from the I2C power but the issue remains. SparkFun's comments on the 3.3v functionality was they've heard anecdotal reports of this happening though the recommend 5V. So future tests will be on 5V until it's working consistently. It did about 200 accurate readings on the 3.3v and then the board crashed, disconnected and the red light came on requiring a power reset. I've also tried adding 4.7K pull up resistors which cause the board to crash immediately upon reading it. Their schematic diagram shows they have internal 4.7K pull up resistors.

Is there anyone who has it working continuously?

I am using the wire lengths which are 8 inches (20.32cm). Though if they needed to be shorter that would be quite impractical.

Just checked SparkFun's site, where I purchased it, and didn't see anything about a firmware update. Apperently it's working perfectly for everyone except one per.

I found this review from someone who apparently used a logic analyzer and found and articulates multiple work-arounds that prevent it from freezing. Though I suspect these work-a-rounds would have to be handled with changes under the ARC hood: "This module seems to have pretty good performance, if you avoid trying to communicate over I2C while it’s busy making a measurement. Plan on waiting 20 ms, and don’t try to use the I2C bus during that time!

If you use simple delays and avoid I2C communication during those delay time, it’s easy to use and works really well."

My above sample code does all I can to prevent reads within a 20ms interval the writer mentions.

Best,

Bill

Bill, can you also try twisting the signal and power wires? That will also help keep interference down on the line. I2c is a strange creature if the correct hardware isn't selected and tested. I believe the lidarlite may not have had extensive tests before final product release - which seems quite common with hobbyist i2c devices anyway :). If you use some of the i2c decives available to hobbyists, such as the sure compass sensor, you will know what I mean. They are super sensitive to be within specific electrical parameters that any characteristics outside of those parameters prevent it from working. Even if a wire is too long or collects too much capacitance.

Hi DJ,

I Just twisted the the 5v wires and ground with the SDA and it still errors after about 200 accurate readings.

I suspect there is some sort of noise issue because when I twist the clock, SDA and power wires together it errors prior to a single reading. I tripple checked all my connections and tried that multiple times because that seemed so odd. That is such unreal sensitivity for the noise coming from a 5v wire to mess it up like that. These devises would create huge vulnerabilities for power line hacks. (youtube Chip Whisperer)

I also just clipped off the dangling Power In and Mode selector wires that were just dangling because of the potential they were picking up signals. I had previously tried grounding them which cause the board to crash prior to a single read. After that test I'm still able to read the 150-400 samples prior to it crashing.

Thanks,

Bill

I have also tried multiple wire lengths, numerous pullup resistors, added many different capacitors and still had the exact same I2C lock up. I am very confident that Pulsed Light may have had some I2C issues with their early sensors. From what I've read they can have the firmware upgraded ( but you'd likely have to send it to them).

Thanks Jeremy,

I'll consider that. I do have a mega I might interface with and connect the EZB to it serially as that genius dude did with all the ping sensors in the Pringles can.

Here is another mode of using the device using PWM. Here the width of the pulse corresponds to the distance.

github.com/PulsedLight3D/LIDAR_Lite_PWM_Fix

At the bottom of page 15 of the manual they describe using the device in this mode. Though technically it's beyond my pay grade. www.robotshop.com/media/files/pdf/operating-manual-llm20c132i500s011.pdf

It's unfortunate they have no competition until you're willing to spend $400-$5000. And these devices appear difficult to interface with.

Best,

Bill

This is what I was just reading on a google group about the Lidar lite April 2015 version (which we have at ezrobot):

Quote:

I recommend pwm mode for that lidar lite Version. They are releasing a new hardware version soon which has significant changes to the i2c interface, it had a blue label.

Link here

You can still pick up the Neato Lidar for around $100. Interface via UART and ASCII output.

Just confirmed my Febuary 2015 version of the LIDAR Lite isn't uselessly defective by getting it to run indefinitely without error on an Arduino Leonardo on the i2C port.

Per the link below, they apparently had an issue with Arduino's original I2C code so I was pointed to the link below for an alternative I2C library to include. Perhaps there's something in this link that might help without breaking existing ARC communications.

www.dsscircuits.com/index.php/articles/66-arduino-i2c-master-library

This code contains some suggested work-a-rounds also that keep the unit from locking up. One issue was when the device would read a zero / zed it would freeze. It would also take longer to return longer distances and it a read request came in prior to it giving an answer it would also freeze.:

/* 

http://pulsedlight3d.com

This sketch demonstrates getting distance with the LIDAR-Lite Sensor

It utilizes the 'Arduino I2C Master Library' from DSS Circuits:
http://www.dsscircuits.com/index.php/articles/66-arduino-i2c-master-library 

You can find more information about installing libraries here:
http://arduino.cc/en/Guide/Libraries


*/

#include <I2C.h>
#define    LIDARLite_ADDRESS   0x62          // Default I2C Address of LIDAR-Lite.
#define    RegisterMeasure     0x00          // Register to write to initiate ranging.
#define    MeasureValue        0x04          // Value to initiate ranging.
#define    RegisterHighLowB    0x8f          // Register to get both High and Low bytes in 1 call.


void setup(){
  Serial.begin(9600); //Opens serial connection at 9600bps.     
  I2c.begin(); // Opens & joins the irc bus as master
  delay(100); // Waits to make sure everything is powered up before sending or receiving data  
  I2c.timeOut(50); // Sets a timeout to ensure no locking up of sketch if I2C communication fails
}

void loop(){
  // Write 0x04 to register 0x00
  uint8_t nackack = 100; // Setup variable to hold ACK/NACK resopnses     
  while (nackack != 0){ // While NACK keep going (i.e. continue polling until sucess message (ACK) is received )
    nackack = I2c.write(LIDARLite_ADDRESS,RegisterMeasure, MeasureValue); // Write 0x04 to 0x00
    delay(1); // Wait 1 ms to prevent overpolling
  }

  byte distanceArray[2]; // array to store distance bytes from read function
  
  // Read 2byte distance from register 0x8f
  nackack = 100; // Setup variable to hold ACK/NACK resopnses     
  while (nackack != 0){ // While NACK keep going (i.e. continue polling until sucess message (ACK) is received )
    nackack = I2c.read(LIDARLite_ADDRESS,RegisterHighLowB, 2, distanceArray); // Read 2 Bytes from LIDAR-Lite Address and store in array
    delay(1); // Wait 1 ms to prevent overpolling
  }
  int distance = (distanceArray[0] << 8) + distanceArray[1];  // Shift high byte [0] 8 to the left and add low byte [1] to create 16-bit int
  
  // Print Distance
  Serial.println("Inches=");Serial.println(distance*0.39370);
}

Hope this helps because this is such a powerful, cheap and easy to use device.

Thanks,

Bill

Just got a response from a Pulsed Light rep about this issue:

Quote:

The issue with I2C communications is related to the fact that most micro-controller I2C drivers do not support a NACK response on the I2C bus - even though that is part of the standard I2C protocol. So to make your sensor work reliably the communications has to operate on a timing only basis. In other words, you would need to wait for the sensor to finish it’s acquisition before attempting to read the data. Typically 20 milliseconds is adequate to avoid the NACK condition. We are also aware of an issue with the Cortex M3/4 processors where any low to high transition of the SDA line without data would cause the I2C peripheral to lock up.

In V2 we’ve completely updated the hardware and this has resulted in improvements in the signal processing of the Signal Processing Core as well as hardwired the I2C port to the chip rather than running it through a soft interface. While these improvements have enhanced performance and added several new features to LIDAR-Lite, the V1 Silver Label sensor is not upgradeable to V2.

I looked up a Lidar lite version 2 on Ebay. Sells for $115.00 Has a blue label with a manufacturing date of July 2015. Does have improved I2c communications and operates at 5VDC.

Hi Jeremie,

It's the curse of the early adopter! :)

I'm able to connect to it on that other board through the EZB UART control with Luis Vazquez methods:
synthiam.com/Community/Questions/6491&page=2

I won't need microsecond levels of accuracy so timing issues won't be problematic.

Thanks much for looking into this.

Cheers,

Bill