irobot58
Resolved by DJ Sures!
This is the first time I have tried using the I2C command and port. The EZ-B browns out (blue tooth is still blinking) when I run the command with nothing attatched at the port. Sometimes it fails right away running the script once and sometimes it takes 3 to 4 times for it to fail. No brownouts occur when not running the script!
I2CWrite(0,0x09,"n",0x00,0x00,0x11) ran Script 2
2/14/2014 3:46 PM - Comm Err: The operation has timed out. 2/14/2014 3:46 PM - BbytesToExpect: 1 2/14/2014 3:46 PM - Received: 2/14/2014 3:46 PM - Disconnected 2/14/2014 3:46 PM - Disconnected 2/14/2014 3:46 PM - Disconnected
second attempt, ran script 4 times and EZ-Board crashed.. following dbug info 2/14/2014 3:47 PM - Attempting connection on COM3 2/14/2014 3:47 PM - Connected to COM3 at 9600 2/14/2014 3:47 PM - EZ-B reports EZ-Robot OS v16 2/14/2014 3:47 PM - Welcome to EZ-B v3! 2/14/2014 3:47 PM - Connected 2/14/2014 3:47 PM - Setting battery monitor voltage: 6 2/14/2014 3:47 PM - Setting battery protection: True 2/14/2014 3:47 PM - Disgard incoming buffer (This usually means your EZ-B requires more power or the communication is unstable) 2/14/2014 3:48 PM - Comm Err: The operation has timed out. 2/14/2014 3:48 PM - BbytesToExpect: 1 2/14/2014 3:48 PM - Received: 2/14/2014 3:48 PM - Disconnected 2/14/2014 3:48 PM - Disconnected 2/14/2014 3:48 PM - Disconnected
I checked the underside of the board for any "shorting issues" at the I2C area with a magnifying glass and found none. I did take a plastic spudder probe and gently rubbed in between all 4 pins. Topside at the prcessor looked clean and free of any possible contaminates. I also, while the EZ was powered up checked voltages at the +5 volts and ground at the I2C pinouts. There was 5 volts at the SCL and SDA pinouts to ground. I dont know if that is normal?! When the EZ-Board was powered downd I measured 70K between SDA and SCL pinouts. The BlinkM type works fine on my "other" board . This is the first time I have tried using the I2C command and port.
I hope someone can verify my voltage readings at the SDA and SCL points to compare my findings. I am not sure what else I can do to further trouble shoot, any ideas would be greatly appreciated
Thanks for any assistance,
Glen
@Herr Ball
I think the issue Abdun was having had to do with the SDK and reading the I2C. The Bluetooth seemed too slow. With the WIFI addition it should overcome the read issue. If you look near the bottom you can see his pic of the I2C port being used and talking to his IMU. We are trying to write to the I2C port ....without anything connected!
@irobot58 are you trying to send I2C commands without the device attached? If so that is probably the problem... When mine was wired poorly and the wires would come off the pins or the wire itself would open circuit it would lock up the EZ-B. I put it down to the command not having anywhere to go to and this causing confusion on the EZ-B and ARC. The same would happen with incorrect I2C commands (more so on my LCD displays but it has happened on other devices too).
@Herr Ball, the BlinkM will connect directly in to the EZ=B without any cables between the two, the pins line up correctly. Try it with the BlinkM directly in the EZ-B and see if the same issues occur, this will at least highlight/eliminate the wiring from the problem.
@Rich Thanks for pitching in here! The EZ-B is failing either with the device plugged in .....or not...ie Bare board(nothing else plugged in) and the EZ board would fail either on the first time the same I2C command was sent or 2, or 3 or 4th run. Confusion is one thing but to have the whole board "brown out " is another. I would definitely like to hear more about your I2C issue with incorrect commands being sent. If your EZB is browning out as well then there must be some weird thing with the Software/hardware relationship. Thanks once again Rich for your attention!
@Rich
I'll try plugging the BlinkM right into the ezb. My next step was to try different pull-up resistors. Been too busy today with family things and must get some sleep now before going out and plowing snow all night. Will let all know how it works hopefully tomorrow.
Thanks again ... as always, the help I get here from everyone is very appreciated!
Well finally got things working. Plugged a second BlinkM I had right into the EZB as Rich stated and all functioned properly. No brownouts! I then thought to test the first one and found that the Red LED did not work at all. Don't know if there is some short in it or what but have to believe that had something to do with all the trouble, strange. When I put power to it before attaching to the EZB and it lite up I thought it was good. Anyway, glad that headache is over. (I tried using 6 inch wires from BlinkM to the I2C plug and all is ok, EVEN without any pull-up resistors.)
May the force be with you!
Hazzah! for you Herr Ball! So glad to hear that it was an device issue! ... but my brownouts are occurring with nothing plugged in
I am fearing the worst , that the board is Fubared! or at least the I2C port
we'll wait until DJ has a chance to suggest something
Just an FYI, I use long wires to my BlinkM which comes off of an I2C LCD and I use no pull up resistors.
@irobot are you sure they are brownouts and not the EZ-B locking up due to nothing being on the I2C Port when you are trying to send a command to a device which doesn't exist? Does it still play up when using the BlinkM plugged directly in to the EZ-B I2C Port? What commands are you using? Does the native BlinkM control work?
Thanks @Rich! all good questions...When I say " brown out" I see the blue led go out and a subsequent loss of connection as per my earlier listed dbug . The issue started when I plugged in the working devices (as it works in the "other" board). When I removed the device and ran the script bare board it still failed but not always on the first run...sometimes the second or third. Yes the BlinkM worked wonderfully with BlinkM Communicator and its " Sequencer" The Command I am running either bareboard(no device) or with device is I2CWrite(0,0x09,"n",0x00,0x00,0x11)....................What I havn't tried is running a "nonBlinkM " I2CWrite script to see if its to do with the BlinkM reference ie "n" or "c" etc! Thanks so much Rich for the further suggestions! I'll report this finding shortly!