
EEGbiofeedback

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: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
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'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
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'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
Link here
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.:
Code:
Hope this helps because this is such a powerful, cheap and easy to use device.
Thanks,
Bill
Sadly because we have a Cortex M3 processor on the ez-bv4 the LIDAR-Lite V1 issue stated above exists. Pulsed Light recommends that we upgrade to the V2 sensor. As @DJ suggested somewhere, they likely released the LIDAR-Lite sensor a bit too early and it wasn't compatible with a bunch of new hardware out there. Looks like they have fixed the issues now.
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:
www.ez-robot.com/Community/Forum/Thread?threadId=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