EEGbiofeedback
Resolved by Jeremie!
Hello,
Lidar Lite causes EZ-B v4 to disconnect after 150-400 reads. Here are the symptoms:
With the sample code in the Lidar Lite tutorial my board is disconnecting and producing the error below. My board's firmware v16.6 hasn't been updated since my November 2014 purchase. I'm using a 9v 200MA wall wart to power the board. And a 5V 1Amp wall wart to power the Lidar Lite. The software disconnects and a non-flashing red light on the board with the blue light continuing to flash.
Below is the output of the error:
7/28/2015 1:42 AM - Attempting connection on 192.168.1.1:23 7/28/2015 1:42 AM - Connected to 192.168.1.1:23 7/28/2015 1:42 AM - EZ-B reports EZ-B v4 OS 7/28/2015 1:42 AM - Welcome to EZ-B v4 Beta! 7/28/2015 1:42 AM - EZ-B v4 ID: 63-54-0-0-47-255-59-57-56-37-38-37 7/28/2015 1:42 AM - Connected 7/28/2015 1:42 AM - Setting battery monitor voltage: 6.6 7/28/2015 1:42 AM - Setting battery protection: True 7/28/2015 1:42 AM - Setting i2c rate: 100000 7/28/2015 1:43 AM - Comm Err: System.IO.IOException: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. ---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags) at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size) --- End of inner exception stack trace --- at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size) at System.IO.Stream.ReadByte() at EZ_B.EZB.(Int32 , Byte[] ) 7/28/2015 1:43 AM - BbytesToExpect: 2 7/28/2015 1:43 AM - ? Received: 7/28/2015 1:43 AM - Disconnected
Here's my code:
$Inches=1
$cnt=0
:loop
$cnt=$cnt+1
ControlCommand("Lidar Lite", RunOnce)
$Inches=floor($lidar*0.39370)
print("Distance: " + $Inches+"Count="+$cnt)
sleep(100)
goto(loop)
Thanks for all you do,
Bill
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 try using the ACK/NAK feature to detect the moment it’s finished, there are a lot of I2C communication bugs. It will pulse the SDA line low for several microseconds for no apparent reason, disrupting communication. If another query is done too quickly after a NAK, it will get stuck with the SDA line low, where the only way to recover seems to be cycling the power. A delay after reading the data, before starting another measurement is also needed, otherwise it will give a copy of the previous reading, or zero.
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