I2C buss

Also, make sure they are all fairly close to each other; I2C was designed for short distances (more than say 20-30 cm start worrying).

shabaz wrote:

 

Also, make sure they are all fairly close to each other; I2C was designed for short distances (more than say 20-30 cm start worrying).

I can find nothing in the Philips specification that limits I2C to 20 - 30 cm (~ 8 to 12 in.). What I do find is a limit of 400 pF capacitance on the

bus. With IC inputs at a conservative 25 pF each allowing for some stray PCB capacitance, and standard 28 gage ribbon cable at 46 pF/m

(AMP.Ansley catalog) it should allow ten I2C devices (250 pF) to be connected with a maximum cable distance of ~ 3 meters (~ 10 ft., 138 pF).

Using connectors will also add capacitance to the I2C bus and should be added in if used. It should be noted that the design of the I2C bus is

not very tolerant to EMI or other electrical noise so keeping distances as short as possible and routing away from any noise sources is a good

idea. Shielding could be used on the cable although this will increase the capacitance of the cable.

Gary Stewart wrote:

Start worrying is not a very informative reply, the follow up is much better.

Whilst all the responses so far contributed to the OP's question, I think your response here does not.

I think we have answered to some degree Chris' original post - to summarize, the answer being yes, but take some care over distance - the

point in my very first post. It can be run to greater distances (over a large chassis for example) but some hobbyists with

Arduino devices may not have test tools beyond a multimeter/logic probe. Running over expensive! shielded cables while possibly

feasible, is an odd suggestion.. if you're resorting to that, why not pick an appropriate protocol.

shabaz wrote:

 

Gary Stewart wrote:

Start worrying is not a very informative reply, the follow up is much better.

 

Whilst all the responses so far contributed to the OP's question, I think your response here does not.

 

I think we have answered to some degree Chris' original post - to summarize, the answer being yes, but take some care over distance - the

point in my very first post. It can be run to greater distances (over a large chassis for example) but some hobbyists with

Arduino devices may not have test tools beyond a multimeter/logic probe. Running over expensive! shielded cables while possibly

feasible, is an odd suggestion.. if you're resorting to that, why not pick an appropriate protocol.

You could easily say the same about this reply. Your first post was a poor response to the question since it clearly left a false impression about

what distance I2C could be used (exactly what does start worrying mean to the "typical" Arduino user you describe here ?), or what could be

done to improve it. Basing your response on an assumption of what equipment may or may not be available to that "typical" user does not help either.

A shielded cable is more expensive but not excessively so and using it has more to do with noise than distance as was clearly stated. The protocol

is not the problem, the physical interface is. It was designed to go over 30 - 40 cm with more than a few devices connected to the bus even at

400 KB/s, but it may require some tweeking of the pull up resistors to get there. If you do not have an oscilloscope to verify the signal intergrity

(not really sure how a multimeter/logic probe helps here since multimeters are usually bandwidth limited to about 1 KHz and neither the multimeter

or logic probe in any way tell you if what is on the line is the correct data at any given time) I would suggest writing a sketch for the master that

continuosly sends data to the slaves and a sketch for the slaves that allows the master to read back the data it sent for say 10 to 20 minutes

while counting the number of errors to make sure it is working properly. Adjusting the pull up resistors might be more than a bit of a problem.

Note, I would only use short wires to verify that the sketches work and that there is an Arduino I2C library that makes writing these sketches

fairly easy. See, that actually says something useful.

Well, post #6 (your post) actually had zero "informative" quality for the original question, yet you chose to criticise my post for this exact reason.

Maybe that irony was lost on you.

As for your (self-stated) "useful" post above:

"not really sure how a multimeter/logic probe helps here since multimeters are usually bandwidth limited to about 1 KHz and neither the multimeter or logic probe in any way tell you if what is on the line is the correct data at any given time"

By the way, I didn't suggest using a multimeter or logic probe if that's what you're implying. I stated (fairly clearly, but maybe there is a language problem), that this is all some hobbyists will have.

Also your comment: "The protocol is not the problem, the physical interface is"

The physical layer is a protocol. It defines the voltages that you expect on the lines amongst other parameters. I2C only has two layers.

Finally your comment: "that allows the master to read back the data it sent for say 10 to 20 minutes while counting the number of errors to make sure it is working properly."

Really.. I'd run it constantly for (at the very very least) days non-stop to ensure I got absolutely zero errors, if I really was attempting to run it over cable (shielded or not) over any significant distance - not that I would design like this. 10-20 mins is insignificant. And sure you can build in reliability in your final code too by error detection/correction, but I'd at least start with a reliable hardware design and test it thoroughly. I'm not so sure there is any benefit or pleasure  in discussing this futher with you. Have a good day.

He was right, the concept for I2C was for short distances, and if you are new to the I2C "sport", then start short, get everything working and then extend.

Some manufacturers make special chips to aid in making long runs.

Best of luck

Andrew Mathison wrote:

 

He was right, the concept for I2C was for short distances, and if you are new to the I2C "sport", then start short, get everything working and then extend.

 

Some manufacturers make special chips to aid in making long runs.

 

Best of luck

There is nothing in the I2C specification from Philips (the originator of the I2C bus) that says it is only for short distances.  The fact that it is designed to work

with a 400 pF capacitive load (max.) and that the description in the specification mentions using it for a keyboard interface (keyboard cables are longer that

20 - 30 cm, 8 - 12 inches) says otherwise.

shabaz wrote:

 

Well, post #6 (your post) actually had zero "informative" quality for the original question, yet you chose to criticise my post for this exact reason.

 

Maybe that irony was lost on you.

 

As for your (self-stated) "useful" post above:

 

"not really sure how a multimeter/logic probe helps here since multimeters are usually bandwidth limited to about 1 KHz and neither the multimeter or logic probe in any way tell you if what is on the line is the correct data at any given time"

 

By the way, I didn't suggest using a multimeter or logic probe if that's what you're implying. I stated (fairly clearly, but maybe there is a language problem), that this is all some hobbyists will have.

 

Also your comment: "The protocol is not the problem, the physical interface is"

The physical layer is a protocol. It defines the voltages that you expect on the lines amongst other parameters. I2C only has two layers.

 

Finally your comment: "that allows the master to read back the data it sent for say 10 to 20 minutes while counting the number of errors to make sure it is working properly."

Really.. I'd run it constantly for (at the very very least) days non-stop to ensure I got absolutely zero errors, if I really was attempting to run it over cable (shielded or not) over any significant distance - not that I would design like this. 10-20 mins is insignificant. And sure you can build in reliability in your final code too by error detection/correction, but I'd at least start with a reliable hardware design and test it thoroughly. I'm not so sure there is any benefit or pleasure  in discussing this futher with you. Have a good day.

The only irony missed here is that you still seem to think that "start to worry" is informative in any context.

No the protocol is not the physical interface. A physical interface is the electrical specification for sending/recieving data across some physical

medium, RS-232RS-232 vs RS-485 as an example. The protocol determines how the data is sent across the physical interface - addressing, byte order,

error detection/correction (which can be done in hardware or software) etc. and it resides in one or more layers above the physical interface.

For a hobbiest, which is what this is aimed for, 10 to 20 minutes will tell you if it is working with reasonable reliability. A 20 minute test at

100 KB/s will have sent/recieved  ~ 100,000,000 bits. If you need better reliablity, run the test for a longer time.

You are right about one thing, this conversation has become a waste of time.

Running for "DAYS" may seem like a good alternative, but its not really, its just mostly a waste of time. It only tests one setup, in one place, one time.

The right way to do it is to build in error correction, so that if your "tested for days system with no errors", suddenly starts getting errors due to sudden circumstances beyond your control like a thunderstorm or simply something has been placed near your cables, or taken away, or a big motor is started or stopped within a mile of where it is, of just ANYTHING, the error correction just cuts in and fixes the poroblems.

To get error correction to work, you also need to actually find out that an error has occurred, so you may need to understand how parity works, plus longitudal error detection as parity will not find a double error always, but its a start.......

I have read all the posts and actually, they all seem to be trying to help the OP, and they also demonstrate to me at least to have more understanding than some here...

Do please remember that someone asked a question, killing the messenger is not helpful or friendly....try to be slightly more forgiving please to those trying to help who maybe did not appear to be "helpful enough" in YOUR eyes.....OK?

Have a great day.

Regards

Andy

If you go to this website:-

http://www.i2c-bus.org/

.....you can read the following, which is simply correct and VERY true:-

---------------------------------------------------------------------

I2C-Bus: What's that?

The I2C bus was designed by Philips in the early '80s to allow easy communication between components which reside on the same circuit board.

-----------------------------------------------------------------------

So it WAS originally designed for short distances.....they should know even if you don't, don't you agree?

Though there are "trix and chips" that can extend it significantly further....but to get really good distances, you need other technology generally speaking.

Just saying that I2C can go long distances, with no qualification that its only with the help of other technology, will generally cause people to heavily question the speaker's knowledge....

Regards

Andy

@Andrew,

I agree with you that a very long test may not be that informative but there are also (reasonably common) cases when error detection does little to help. If, for example, the system timing is marginal it may got from an error rate of less than 1 bit in 1E9 to 1 bit in 1E2 as the temeperature changes from 20C to 30C. Error detection folowed by re-transmission probably won't save you. It's still a very good idea to have it because it's a big step on the way to measuring and ultimately dealing with the source of the problem.

I would expect a professional designer to check the bus timings/waveforms with a scope but of course this may not be possible for many hobby engineers. The answer there is to be careful to work well within specs, try to conform with common good practice (short spans and error correction) and be perapred to be innovative in your debugging.

MK

Andrew Mathison wrote:

 

If you go to this website:-

 

http://www.i2c-bus.org/

 

.....you can read the following, which is simply correct and VERY true:-

---------------------------------------------------------------------

I2C-Bus: What's that?

The I2C bus was designed by Philips in the early '80s to allow easy communication between components which reside on the same circuit board.

-----------------------------------------------------------------------

So it WAS originally designed for short distances.....they should know even if you don't, don't you agree?

 

Though there are "trix and chips" that can extend it significantly further....but to get really good distances, you need other technology generally speaking.

 

Just saying that I2C can go long distances, with no qualification that its only with the help of other technology, will generally cause people to heavily question the speaker's knowledge....

 

Regards

 

Andy

Again, that is not what is said in the Philips (the originator of the I2C bus) I2C specification in their data books. Of course there is a trade off between the number of I2C devices

you are connecting to and the distance allowed between them. The original post was for three I2C devices at a conservative ~ 25 pF/device which allows for a lot of leeway

for distance.

Edited to include this:

Philips always promoted the I2C bus as a multi-purpose digital communications bus that could fill several roles including connecting one or more devices on a PCB

or between one or more devices over a cable. A good example of the latter is its use in late gereration VGA monitors (over several feet of cable I might add) that

allowed the computer to download timing and other information from the monitor so it could automatically configure the video card to work with it. It should also be

noted that the SMB bus which is a slight variation of the I2C bus is used on PC motherboards to communicate with hardware monitors, memory modules, and

anything else connected to it and that it is sometimes available for external devices via a connector on the motherboard. Finally a lot of video camera modules

have another slight variation of the I2C bus which is used to set a long list of parameters in the image sensor.

Andrew Mathison wrote:

 

If you go to this website:-

 

http://www.i2c-bus.org/

 

.....you can read the following, which is simply correct and VERY true:-

---------------------------------------------------------------------

I2C-Bus: What's that?

The I2C bus was designed by Philips in the early '80s to allow easy communication between components which reside on the same circuit board.

-----------------------------------------------------------------------

So it WAS originally designed for short distances.....they should know even if you don't, don't you agree?

 

Though there are "trix and chips" that can extend it significantly further....but to get really good distances, you need other technology generally speaking.

 

Just saying that I2C can go long distances, with no qualification that its only with the help of other technology, will generally cause people to heavily question the speaker's knowledge....

 

Regards

 

Andy

Again, that is not what is said in the Philips (the originator of the I2C bus) I2C specification in their data books. Of course there is a trade off between the number of I2C devices

you are connecting to and the distance allowed between them. The original post was for three I2C devices at a conservative ~ 25 pF/device which allows for a lot of leeway

for distance.

Edited to include this:

Philips always promoted the I2C bus as a multi-purpose digital communications bus that could fill several roles including connecting one or more devices on a PCB

or between one or more devices over a cable. A good example of the latter is its use in late gereration VGA monitors (over several feet of cable I might add) that

allowed the computer to download timing and other information from the monitor so it could automatically configure the video card to work with it. It should also be

noted that the SMB bus which is a slight variation of the I2C bus is used on PC motherboards to communicate with hardware monitors, memory modules, and

anything else connected to it and that it is sometimes available for external devices via a connector on the motherboard. Finally a lot of video camera modules

have another slight variation of the I2C bus which is used to set a long list of parameters in the image sensor.

If anyone interested in defining "distance" problems would like to check I believe page 60 of the most recent I2C manual "UM10204", has a note with regards to bus lengths above 10 cm requiring careful & correct planning:-

if the length of the bus lines on a PCB or ribbon cable exceeds 10 cm and includes the VDD and VSS lines, the wiring pattern should be.......

There is a note further if only the Vss line will be carried.

It also mentions that the problems lie with the sensitivity of the signal lines to interference, NOT JUST CAPACITY AS MANY BELIEVE, which is of course important as well, both must be considered when designing and building. Capacitance is not the whole story:-.

The bus lines are most susceptible to crosstalk and interference at the HIGH level because of the relatively high impedance of the pull-up devices.

Plus, there is no need for a "war" about this subject as someone else correctly mentioned, but these facts are easily found in the "Bible" fron NXP, so anyone can check for himself as needed.

If anyone would like to download a copy of the I2C manual, from the original designer, I found probably the most recent one (Rev. 5 — 9 October 2012) here:-

http://www.nxp.com/documents/user_manual/UM10204.pdf

I personally believe that if we are to assist anyone new to this bus, he should understand a) where all the necessary documentation can be found and b) have information given in a friendly and free manner with regard to what many might regard as oddities for example.

Others here have already correctly mentioned that there are several other methods around to increase the signal path distance, often with other types of technology that are relatively easy to implement if and when required.

It is probably true to say that a "dyed in the wool" I2C expert can get longer lengths of bus up and running, but that is not really the place to start for a probable beginner, furthermore, the needed equipment to fault find and fix faults if the occur may be outside the budget of many people....

By the way, www.NXP.com is the "follow-on" from Phillips, so this is a fully official manual that could help many

I also like the Wiki page:- http://en.wikipedia.org/wiki/I2c#Limitations

as it has many useful links including I2C tutorials if required.

Regards to all and best of luck.

Andy

Andrew Mathison wrote:

 

If anyone interested in defining "distance" problems would like to check I believe page 60 of the most recent I2C manual "UM10204", has a note with regards to bus lengths above 10 cm requiring careful & correct planning:-

if the length of the bus lines on a PCB or ribbon cable exceeds 10 cm and includes the VDD and VSS lines, the wiring pattern should be.......

 

There is a note further if only the Vss line will be carried.

 

It also mentions that the problems lie with the sensitivity of the signal lines to interference, NOT JUST CAPACITY AS MANY BELIEVE, which is of course important as well, both must be considered when designing and building. Capacitance is not the whole story:-.

The bus lines are most susceptible to crosstalk and interference at the HIGH level because of the relatively high impedance of the pull-up devices.

 

Plus, there is no need for a "war" about this subject as someone else correctly mentioned, but these facts are easily found in the "Bible" fron NXP, so anyone can check for himself as needed.

 

If anyone would like to download a copy of the I2C manual, from the original designer, I found probably the most recent one (Rev. 5 — 9 October 2012) here:-

http://www.nxp.com/documents/user_manual/UM10204.pdf

 

I personally believe that if we are to assist anyone new to this bus, he should understand a) where all the necessary documentation can be found and b) have information given in a friendly and free manner with regard to what many might regard as oddities for example.

 

Others here have already correctly mentioned that there are several other methods around to increase the signal path distance, often with other types of technology that are relatively easy to implement if and when required.

 

It is probably true to say that a "dyed in the wool" I2C expert can get longer lengths of bus up and running, but that is not really the place to start for a probable beginner, furthermore, the needed equipment to fault find and fix faults if the occur may be outside the budget of many people....

 

By the way, www.NXP.com is the "follow-on" from Phillips, so this is a fully official manual that could help many

 

I also like the Wiki page:- http://en.wikipedia.org/wiki/I2c#Limitations

 

as it has many useful links including I2C tutorials if required.

 

Regards to all and best of luck.

 

Andy

The document you talk about does not include the "careful and correct planning" phrase.  It does specify the order of signals on the cable to minimize noise and

crosstalk on cables over 10 cm which is not hard to follow. In the case of connecting three Arduinos together there is no need to supply Vdd to the far end as it

already has its own power supply but Vss will need to be connected.

If you read my previous posts you would see that I also mention that it is susceptible to noise, and that I give a couple of useful tips on how to check out and

work around this without using any specialized equipment other than the Arduinos themselves, a little test software using existing Arduino libraries, and maybe

shielded cable. Using the correct cable layout will definitely help. If you read the spec. you reference you should notice that the capacitance of the signal lines

(cable or otherwise) is by far the most frequently mentioned factor in limiting the ability to use the bus both at speed and over distance due to the specified

current sinking capacity of the drivers, hence the high value pull-up resistors. This has not changed from the original specification.  The newer specification

does include driver changes required by the high speed and Ultra-high speed versions.

As mentioned in my previous post I2C was used by many brands of VGA monitors over several feet (6' to 9') of cable accompanied by some high speed analog

signals in the same cable. At these distances some tweaking of the pull up resistors would probably be required but the amount of tweaking is still limited by

the current sinking capacity of the drivers themselves. Tweaking these resistors for such distances can still be done, albeit more slowly, with no special

equipment other than the eqiupment mentiond previuosly, some resistors, and a soldering iron assuming soldering is included in a beginners skill set of

course. From the original posters description I did not expect to need that kind of distance anyway so I'm not sure why any special extension drivers would

be needed.

While the official bus specification is by far the best source of information on the I2C bus, I would be very surprised if a beginner as you put it could make heads

or tails of most what it says. Clearly such a document requires much more than just a beginners knowledge of AC and DC electronics. That is why these forums

exist. However, sometimes the information on the forums is less than useful ("over 10 - 12 cm, start worrying"), and when someone else steps in with better

advice it is perceived as hostile. OOOKAAA.

There was no war of words, only an ongoing attempt to reply to some less than useful opinion with slightly more useful information.

It's good points. I must admit I did get curious to do the math, and even at these low frequencies (400kHz) 100pF has an impedance of around 4k. So the crosstalk would be bad as you say, no matter how hard one can (practically) pull up the open drains. 400pF would be pretty severe. Nowadays people run I2C at (say) 3.3V too, making the problem worse.