I am having the same trouble! Today is the first time using the BlinkM and the I2C port and EZB keeps browning out. What can we be doing wrong? I even tried to power the BlinkM from another source and still the same thing. I don't have any trouble until I run the BlinkM script. Unlike you though I lose my blinking blue light on the board and can't get it back until it's unplugged from power and then plugged back in. Will keep working on solving the problem but just wanted you to know I'm having trouble here too.

@Herr Ball I tried the very same thing as well! " I even tried to power the BlinkM from another source and still the same thing." Have you tried testing with a volt meter on the SDA and SCL ? I am wondering if the 5 volts tested is normal or not! Also across the two , powered down, on the ohm scale.

What other peripherals are connected to the EZ-B when you are testing the BlinkM?

A few issues I have had with I2C which may guide you in the right direction (they may not though) are;

Brownouts caused by the HD servos, moving the servos on to their own supply solved this. The issue was more on the servos than I2C but it did cause some funny behaviour which is why I am mentioning it.

Connections being reversed on the SDA and SCL. This locked up the EZ-B was unresponsive until power cycling.

Loose connections/poor wiring also has caused some strange behaviour, then the SDA and SCL aren't connected or the connection drops somehow (usually through low quality wiring that open circuits) it would lock up the EZ-B and power cycling was needed.

I'd say check the connections on the SDA and SCL to the BlinkM. Check the resistance of the wiring and make sure it's low and doesn't fluctuate too much when the wiring is moved.

Also check the Vcc and Ground. The BlinkM has points on it for an external source if needed or just run Vcc and Ground from another 5V source with more current available.

I can confirm that my BlinkM has run fine plugged directly in to the I2C port, it's also worked fine when daisy chained on my LCD display. No pull up resistors are used on my I2C lines.

@DJ no other peripherals or BlinkM ..bare board! ...and sometimes it fails on the first command I2C script run and other times the third or fourth run. I am thinking there may be an issue with the board (out of warranty) If someone could check the voltages individually on the SDA and SCL to compare with my readings It will confirm or deny my suspects.

@irobot58

My I2C 5 volt pin is putting out the 5 volts it should. The voltage from the SDA and SCL pins are putting out 5 volts to ground also. I reread the manual and still can't figure what is going on. I have not tried any other I2C devices as I have none.

Just wanted to let you know about the voltages you ask for. Back to pulling out some more hair, something there is not a lot of anymore ... LOL.

Oh and DJ, I am not running anything else at the time of the brownout also.

@Herr Ball

Thanks for the update! Very interesting that there are two boards doing the same thing under the same circumstances. Thanks for testing the SDA and SCL leads . I hope this info helps DJ think of any further ideas to correct this issue... I am fearing the worst as it might be an internal board issue .....we''ll see what DJ says PS ....I can empathize about the pulling of hair! I think I might pull armpit hair instead! LOL

Please read the top paragraph. There seems to be a issue with the I2C. I assume it affects us too?

synthiam.com/Community/Questions/5131

@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!

My regrets for this lengthy post but it may help with further trouble shooting:

Just to be sure I am using Firmware V16 and Release 2014.01.07.00 I know there was a I2C Write Read fix on Release 2013.07.24.00

I tried this I2C command as well(No device) I2CRead(0,Auto,0x03,2) It responded "with syntax error: unknown command" I also tried the other ack's as well, True,False.

I2CWrite(0,0x09,244)This variation also failed(decimal) I2CWrite(0,0x09,0x02,0x05,0x06) This was ran 5 times before Blue light went out. This script was run and failed on the second I2CWrite, just after the 2000 delay. I2CWrite(0,0x09,0x02,0x05,0x06) sleep(2000) I2CWrite(0,0x09,0x02,0x05,0x06) sleep(2000) I2CWrite(0,0x09,0x02,0x05,0x06) sleep(2000) I used a different address this time. This ran nicely until the last command and failed. I2CWrite(0,0x03,0x02,0x05,0x06) sleep(2000) I2CWrite(0,0x03,0x02,0x05,0x06) sleep(2000) I2CWrite(0,0x03,0x02,0x05,0x06) sleep(2000) I2CWrite(0,0x03,0x02,0x05,0x06) sleep(2000) I2CWrite(0,0x03,0x02,0x05,0x06) sleep(2000) I2CWrite(0,0x03,0x02,0x05,0x06) I ran this script again and failed on the first command.

And this command failed first time I2CWrite(0,0x03,0x02)

Is that with the BlinkM plugged directly into the I2C port on the EZ-B or do you have wires between the two?

It may also pay to check the underside of the EZ-B for any shorts between the SCL and SDA of the I2C port.

@Rich (No Device) bare board with no other devices plugged in. I did go over the underside of the board with a plastic spudder probe and a magnifying glass no apparent shorts. Electrically with the ohm meter it read 8k across the SCL and SDA. SCL to grd 5k. SDA to grd 5k. Only 4 k SCL and SDA to the 5volt pin! (I2C port) ...and 1k across the grd and 5v (I2Cport).

Without another EZB to compare readings I don't know if these are normal or not(hardware issue or software) Perhaps DJ may have another insight when he gets back from the big apple

Thanks again for your time @Rich Glen

Just out of interest (and confusion) why are you trying I2C commands without the device attached?

When I get chance I'll measure the voltages and resistances of one of my EZ-Bs, although I don't know when I will get the chance so don't hold your breath for that one.

@ Rich I would like to determine if its the device causing the issue or the software or the board. If you or anyone else can take some simple resistance readings that would pretty much conclude what is the issue. I know the device works in the "other board so it must be either the EZboard or the software. It seems strange that the I2CRead command is not being recognized as well!? I am using the exact same example in the Script descriptions!? You have spent far too much time trouble shooting my issue and I appreciate that greatly If the board is hooped then its a matter of getting another. Perhaps a reload of the software or Version upgrade may take care of the I2CRead.

Did you try I2CRead with quotes around Auto? Also, it needs to put the returned data somewhere so it needs to be $variable = I2CRead()

I can't say I've used I2CRead so the above is pure guess work based on what I know of EZ-Script rather than the specific command.

Indeed! I did try the command with the $variable as per the example given in the Script commands. The examples don't show Auto with quotes so no I didn't but will try this right away! and with the $variable = I2C Read() as you suggested.....

No Joy ..... The variable addition had no effect

Try $variable = I2CRead(0,"Auto",0x09,2)

By $variable = I2CRead() I meant the command but was too lazy to fill in the parameters.

While I2CRead() is a command it is useless without it being assigned to a variable, ARC would read it but instantly forget it. If you think about it, how would you use the information read by the I2CRead() command without it being assigned to a variable or used as part of an IF nest etc?

Either assign it to a variable so you can call on that variable later i.e.

Print($variable)

or use it as part of another command i.e.

If(I2CRead(0,"auto",0x09,2) = 0xFF) Servo(D0, 90) EndIf

No syntax error on your "If(I2CRead etc example! yay progress with the Read command!...but...

I am afraid the $variable has no bearing on the Script because it always fails a syntax check every time at the "Read"...and ....I2CRead does not come out on the Script helper window!? ie when entering anything on the Script line a blue helper window opens up...but nothing shows for I2CRetc?! I think I better upload the latest Software version to eliminate any corruption in my copy! and retry everything

After deleting the old version(Best practice) I installed the latest version and retried the I2CWrite and I2CRead commands with exactly the same results! No I2C help window for the I2CRight unknown command etc and the Write command still browns out the EZBoard.

The best example for I2C (and the BlinkM) is the I2C example in ARC.

Getting the RGB values is already written;

# Shift the bits over
# Set the LSB (first bit) to a 1
# When first bit is a 1 on i2c, that means
# it is a Read Address
$i2cAddress = 0x09

Print("BlinkM Address: " +  $i2cAddress)

# Tell BlinkM we want the RGB Values
i2cWrite(0, $i2cAddress, 0x67)

# Receive the RGB Values
$raw = i2cRead(0, AUTO, $i2cAddress , 3)

# Print the number of bytes
Print("Received: " + Length($Raw) + " Bytes")

# Print the hex value of each byte
PrintHex($Raw)

# Split the array of bytes and assign to each variable
$Red = GetByte($Raw[0])
$Green = GetByte($Raw[1])
$Blue = GetByte($Raw[2])

From that you can see that first the I2C device is written to with I2CWrite(), it asks for the RGB values, then the variable $raw is assigned the values with the I2CRead command.

It also shows that Auto doesn't need to be in quotes after all.

The example shows how to use the I2CRead command correctly by defining a variable, in this case $raw.

Thank you @Rich ...That is a very good example but immediately my board browns out (blue light goes out and red Bluetooth begins to blink) with the device plugged in. The I2CRead as a variable does not fail as a "syntax error :unknown command "
Does the I2CRead command always have to be written as a variable? Why cant it stand alone as a Command? and why doesn't the Read come out in the blue helper window when writing on the command line? I am fairly sure all the other commands are given in the helper window.

I2CRead is covered by the help in the right side of the script dialogue but it doesn't come up when you start to write it, there are a few other commands which don't either, usually when they aren't the first command on the line.

To help you understand why I2CRead can't be used as a stand alone I'll ask, in what scenario do you see you using it as a stand alone command?

It doesn't have to be set to a variable, you can use it in an If or in a Print etc. but running just I2CRead(0, Auto, 0x30, 3) would return a result and then what? It needs to store it as something or do something with it. The same applies to GetPing, GetADC, HTTPGet amongst others.

Thank you @Rich (who is doing an all nighter! tired) ...I just assumed all commands where "helped"..thats only a very minor issue but clarified! I believe now, with your clarification , I2CRead is only ever used within a Variable as in the example given on the right side Script definitions! ..
Would that be the reason I am getting "syntax error :unknown command " when its the only command on a script line? If that's the case , then now we know! and I should open a software issue help and can give you the deserved credit for that, tomorrow when your awake! The Write issue will be separate and is yet not resolved... I just need to know if its a board issue or software though I am leaning on the board! 80% (why isn't the board browning out on the very first run but sometimes the second or third or 5th?)

Don't worry about giving the credit, I have enough already to let one or two go by without receiving any

When I2CRead is the only command on the script line the syntax is incorrect. The Unknown command is a little misleading since the command is known, it's just been used incorrectly. Think of it (and any of the other Get commands) as data than as a command. Similar to if you just put "Hello World" on a single script line, it means nothing without another command, or like math commands i.e. $ping / $date these mean nothing without a command such as $variable or Print or IF.

Really thanks so much @Rich! My primitive understanding is obvious but since you have been giving your knowledge and experience generously on this forum my own understanding has grown immensely and along with many others. This I2CRead "statement" was not well described in great detail as it is here!
Have a great day!

I haven't forgotten about this I've just been real busy. I'll grab my test board in a bit and do some checking. I don't have my BlinkM easy to get to since it's in Melvin's head at the moment and Melvin is a little worse for wear at the moment (don't ask!) but I'll check out the resistances and voltages for you as a benchmark. Give me an hour or so and it'll be done

Gnd to Vcc = 4.99v Gnd to SDA = 4.96v Gnd to SCL = 4.96v VCC to SDA = Open/0V VCC to SCL = Open/0V SDA to SCL = Open/0V

Gnd to Vcc = Open Circuit Gnd to SDA = Open Circuit Gnd to SCL = Open Circuit Vcc to SDA = 4.63k VCC to SCL = 4.59k SDA to SCL = 9.25k

Also, run the script

I2CWrite(0,0x03,0x02,0x05,0x06)
sleep(2000)
I2CWrite(0,0x03,0x02,0x05,0x06)
sleep(2000)
I2CWrite(0,0x03,0x02,0x05,0x06)
sleep(2000)
I2CWrite(0,0x03,0x02,0x05,0x06)
sleep(2000)
I2CWrite(0,0x03,0x02,0x05,0x06)
sleep(2000)
I2CWrite(0,0x03,0x02,0x05,0x06)

It made the EZ-B blue light turn off, a few moments later bt disconnected. I'll do some more digging. This was without anything attached.

I just tried Melvin again, and on init he was disconnecting. My init script starts up both the BlinkM and LCD which are both on I2C. I changed the init script so it didn't run, connected, was working fine, tried to init the LCD and blue light went out and disconnected the EZ-B.

I can't be 100% sure it isn't my robot that is to blame but it does seem coincidental that any I2C commands are being problematic on both of the EZ-Bs I have running. Both doing the same thing. Even using the built in BlinkM control was causing problems.

I will do more playing around when I have more time but as it stands it does seem like the issue is not with your EZ-B but may be with ARC...

Hopefully someone else using I2C can comment on if they are having problems with the latest version so we can get as much info as possible together to help diagnose/solve the issue.

Update:

Is this what happens to yours?

@Rich ..Yes that's exactly whats happening! and your quote " Hopefully someone else using I2C can comment on if they are having problems with the latest version so we can get as much info as possible together to help diagnose/solve the issue." My I2C was failing on Release 2014.01.07 and then upgraded to the current release, same issue. Curiouser and curiouser! Three different boards same software? Thanks once again Rich!

If nobody chips in within a few days I'll drop @toymaker an email since I know he uses I2C a lot but may have missed this topic.

I will admit, I haven't used I2C for a while (I haven't used ARC for a while - I've seriously been neglecting my robots lately) so I don't know when it may have started to play up. If it's still installed I'll try it on my office PC which I know was working, this will rule out the slim chance of it being pure coincidence.

I know there was a I2C Write Read fix on Release 2013.07.24.00......I know @DJ could spread a bit more light on those updates! We all "neglect" our robots building from time to time but that just allows more focus the next time All my servo scripts are working just fine. whew

Hey all

Strange things here trying to reproduce my problem I had before. It was the same trouble that Rich shows in his video, exactly the same thing! Thought it was my BlinkM that was bad and causing the EZB to brownout. Tried another BlinkM and all was/is ok. Wanted to try and help out here so I decided to try the original BlinkM and see if some way some how to figure this out. Well your not going to believe this but now the original BlnkM works and does not brownout the EZB? Can't figure out what or if I did anything different.

Thought I'd let you guys know and will continue to look further. Using and older version 10-28-2013.

Thanks for chiming in Herr Ball! What script are your running on the BlinkM that is not " browning " out your board. So the version your using is "Post" fix of the I2C... Our boards are "browning" out "bare" board with nothing plugged in and running an I2C Write script! Can you run your script repeatedly ? Also take some voltage and ohmage readings on your I2C port to compare with Richs if its convenient. Thanks so much Herr Ball!

I am running the BlinkM on the BlinkM script. The one that comes with EZB with the 3 different color sliders. Although I have several servos attached to the board, nothing was running at the time but the BlinkM script. As I stated, I can run either BlinkM and the board does NOT brownout now! NO changes where made from the time of brownout till tonight. I just don't understand why it started working here.

As for board readings, all mine are close to Rich's. I do get on the sda to scl = 7.22k, thats a little off from his.

Getting late here, will try again tomorrow.

The resistance difference may be down to the adapter board I was using to access the I2C pins, although 2k is pretty high, I may check that again when I get the chance.

Hopefully I'll have some time this weekend to dig a little deeper and see what's what. I don't think Brownout is the correct term for what is happening but the more info we can get together the easier it will be to solve. It may be something simple although my concern is Melvin wouldn't work and my PC hasn't changed at all other than updating ARC, on the wiring side of things Melvin hasn't changed either but I'll double check that as I can't be 100% sure something hasn't come loose inside him.

@Rich ..Awesome!

@Rich, any luck with getting in touch with @Toymaker regarding his I2C experience? Have you retested Melvin again? I don't really want to contact the EZB department until we have explored all angles! I don't understand why everyone else's I2C is working but ours are not!?

Not yet, to be honest I haven't had time. I did check and my other PC has an old version on it still which is likely to be the version which I know had no I2C problems so I'll give that a try in a bit (it's on since I have some work to get done tonight, I just haven't had the desire to go up to my office and get it done yet...)

Just tested my BlinkM in Melvin (without changing anything since my video the other day) on version 2013.06.06.00 and it worked fine, no problems, no disconnects.

I haven't tried it on the current release so it may have been updated and fixed for all I know however I would say that everything is pointing towards the release I used when I made the video has an error with the I2CWrite. When my memory card turns up for the Acer W3 I'll try it on that with both 2013.06.06 and the current version using the same project and same robot with no changes to anything other than the version of ARC being used, this will pinpoint if it is a software error.

@Rich ..great work, we're starting to "surround " this trouble! From an earlier note " I know there was a I2C Write Read fix on Release 2013.07.24.00 " ...As was stated earlier from me, it was failing with the current release and one from January, we'll see what your testing with the current version reveals!. If the I2CWrite and port needs a device on it to function...then I am good with that, but everyone would need to know that. Is the 2013.06.06.00 version in your "cloud memory" ? Perhaps I could download it and test as well!

I am having problems as well and I had a accelerometer hooked into the I2C and the EZ B shuts off. I tried with the device unplugged from the EZ B and still the same result. confused

@shamon thanks for your input! The plot thickens....Rich said his I2C works with an earlier version (thread #48) , a version before I2C issues were fixed. hmmmm ........... What version are you using?

I am using the most current software version and the Ez b 3 with the firmware version 16. The newest one. I am thinking this has to be a software issue from all the forum talk.

@shamon I am thinking of contacting " Contact us" as the I2CWrite issue has not been resolved. They may provide more insight. There are 3 boards that are doing the same malfunction and it now seems to be pointing to the software. Rich has done his best to test from his end. I know DJ is extremely busy with the V4 release but perhaps one of his team members can check it out. If I had saved an earlier version that is known to work per Rich , we could at least test it as well.

I've mentioned it to Jason just on the off chance that nobody at EZ-Robot had picked it up.

I'll still be testing one more thing later which is to use 2013.06.06 (known working version) and the latest on my Windows tablet, same PC, same robot, no change other than the version of ARC, that should pretty much pin point if it is software based.

Hey guys,

Sorry we have been quite busy these days with the wave of interest that came after the Toy Fair. I have just verified the bug and will pass it on to DJ to squash when he has a spare moment. Thanks for the heads up on it!

Excellent. That saves me having to downgrade ARC to test it (since updates rarely break things I wanted to be sure before passing it over to DJ).

Once again Thank you Rich and @skater!

This is my second thank you to DJ for resolving this issue ! My full joy and gratitude is expressed in DJ's Release Thread!

Disgard incoming buffer of 2 Bytes (This usually means your EZ-B requires more power or the communication is unstable) i am facing this problem please help me

Tell us more please.

What type of power source are you using? It needs to be big enough to handle the load demands (your wiring also) What devices or motors are you using when this issue occurs? Something may be drawing power away from the device or EZB you are trying to get to work. Have you checked to make sure all connections are tight and properly made? i2c connections are notorious for failing if there is a lose connection. How are you connecting to ARC? If using WIfi are you using the default EZ-B v4 Wi-Fi setting , AP Mode (also called Wi-Fi Access Point or AdHoc) or are you using client mode? Either way make sure you have a good strong signal. If in client mode make sure you are on an uncluttered channel. Here's a connection troubleshooting guide: connecting-and-troubleshooting HTML

Good luck.

Ezb disconnecting support: https://synthiam.com/Support/troubleshooting/EZB%20Disconnecting