When you need many sensors at once...

"Not that old story again. You discussed this quite a while back:"

Yes I remember it well and yet here you are again pushing the easily dis-proven idea that I2C is only good for short distances between boards.

"If we take the time to analyze the signal on the wire then sure you can push I2C"

Given the number of cable lengths, the number of different devices it is connected to and how they are terminated at both ends of the I2C interface, it appears that

it is easier to push than you think.

" but I think it is fairly clear that if the person asking the question doesn't know how to connect multiple same-address sensors then they may not have access to an oscilloscope or even know what to look out for - hence the gentle probing about their use-case."

So many assumptions.

"At a first approximation, I2C is typically used for on-board and board-to-board communication within an enclosure, with some exceptions being the cable you refer to"

Given the vast number of DVI (yes it is used on these cables as well) and HDMI cables in use in computer and video entertainment equipment I don't see how you

come to the conclusion that these cables are the "exceptions", my first approximation would be that they are the rule. And even if they are the exceptions they still

prove I2C is used on cable over long distances on a great number of devices.

"it's an exception that works because engineers examined the signal on the wires in detail."

Given the number of cable lengths, the number of different devices it is connected to and how they are terminated at both ends of the I2C interface quality engineers

can not possibly examine the signal on the wires in detail for all those variations and yet it still works.

"If you have (possibly) limited hardware and test tools and using whatever cable is at hand, then you wouldn't use it across 25 feet.

In fact you yourself came to some similar conclusion when you stated on that thread"

Re-checked the thread and as far as I can tell I said no such thing.

"so keeping distances as short as possible and routing away from any noise sources is a good idea"

Keeping distances short is always a good idea with any single ended communications interface, it's just not always possible, and you can still get I2C to work over

long distances when it is not.

I need to take multiple G readings across a device that is a cube about 1-2 feet.

I do know that I2C has its limitations, but in practice it works well for a protocol for external sensors.

I could attach an Arduino or some MCU to each sensor and then use serial across the MCUs but that is a waste just to "follow the rules" 

I'm going to look into the multiplexor!

Going beyond i2c's limits - particularly at lower speeds - is possible, screamingtiger. But I concur with shabaz that this is a stretch: can be done, but at a cost/risk.

I think that using a protocol outside its original habitat is an advanced topic.

I always respect people that get more out of something than the original designers intended.

But also feel that it shouldn't be the first design option when engineering something.

Stretching protocols for your need would almost be a last resort....

Keep us posted on the multiplexer, please.

I would put all sensors on the same I2C bus and make some address decoder to make only one device active at a time.

Do you have a  decoder example, kulky64?

I'd be interested in a usable example too (not looking for 25+ sensors, but would be helped if you know one for using two fixed-address ICs).

If you have device with only one fixed address, then this is not usable. But if device has at least one hardware pin to set I2C address, then it should be possible to dynamically change logic level on that pin(s) using some spare GPIOs or logic decoder to make only one responding to MCU. This may not be usable to all I2C devices. For example if device scans logic level on its address pin only during power-up or reset and then assumes that address until next power-up/reset.

Linear Technology makes chips to handle this situation - up to 127 devices with the same address can be handled on one bus, but you may need one of these chips at each sensor. They cost about $2 each.

LTC4316

LTC4317

LTC4318

Linear Technology - Product Page

http://cds.linear.com/docs/en/datasheet/4316fa.pdf

yet here you are again pushing the easily dis-proven idea that I2C is only good for short distances between boards

Where did I state with the explicitness that you suggest, that it is only good for short distances? Engineers try not to speak in absolutes, but they certainly make approximations, to convey ideas.

You don't have permission to edit metadata of this video.

Edit media

Dimensions x Small Medium Large Custom

Subject (required) Brief Description Tags (separated by comma) Video visibility in search results Visible Hidden

Parent content

RE: When you need many sensors at once...

Poster

Upload Preview

Ok

Cancel

You yourself stated a similar guideline yourself,.. I'm only quoting you from your earlier thread..

"so keeping distances as short as possible and routing away from any noise sources is a good idea"

The video interface (built to a low cost) is still an exception, people don't use I2C for any significant distance generally. ("Generally" does not mean "only" by the way..).

And I suspect there are plenty of cables from cheap vendors that fail for this reason, leaving the user wondering why their video devices need manual configuration..

And, in some products ("some" does not mean "all", just to be clear, although I'm beginning to feel only you need this level of clarification since you tend to see things that are not really written) it would be a joke to even consider I2C outside the enclosure. Furthermore it would be a dumb thing to promote the use of I2C over a long distance for people trying to learn by asking advice, and setting them up for a fall if I suspect they may have an undefined cable and undefined level of test equipment. I'd rather make them aware, and learn more about the use-case, and give them some information that they can take and use with confidence. This isn't "pushing" a non-I2C agenda/conspiracy. That would be as daft as it sounds.

Sure, NXP recently created a marketing paper promoting multi-kilometre use (with many repeaters!) - took them 25 years to get around to it, so clearly not a popular scenario - it was published in 2014.

Anyway, reaching out to my latest copy of 'Art of Electronics' - famous for practical real world guidance- the authors, Paul Horowitz and Winfield Hill too suggest (on page 1032) that typically [amongst other serial busses, I2C is] an internal serial protocol, chip-to-chip and within an instrument.

You might well wish to use I2C for long distance use but real engineers tend to ("tend to" != "only") use it conservatively for short distances because there are better long-distance protocols.. (by the way, I am qualified and was a Chartered Electrical Engineer before I moved on to other equally technical jobs, i.e. recognised by my peers and my professional body (IEE, now IET) to have satisfied practical experience in the field of electronic engineering as well as achieving educational qualifications in the same field (electronics).

In the 4 or 5 years I've been a member here I have never had to state that and put my cards on the table, but it's tiring discussing this mundane I2C topic with you. Sensible readers can decide for themselves if they wish to use I2C over long distances and what precautions they would take. If they ask for such advice, then it can be stated as fact that I'm giving my advice based on experience designing with it in industry, not just from using the controlled design cable that is VGA.. I'm not 'trying to push' an idea as you suggest, for any other reason - if I did, I wouldn't be living up to the standards that I try to always maintain..

Interesting part!

I've not seen such a address translating device before.

"Where did I state with the explicitness that you suggest, that it is only good for short distances?"

Geeze this is easy. Direct quote from your second response "I2C isn't intended for long distances". Direct quote from the previous response:

"it would be a joke to even consider I2C outside the enclosure". There is nothing in the NXP I2C specification or real world use that supports either of

these statements.

"Furthermore it would be a dumb thing to promote the use of I2C over a long distance for people trying to learn by asking advice, and setting them up for a fall if I suspect they may have an undefined cable and undefined level of test equipment. I'd rather make them aware, and learn more about the use-case, and give them some information that they can take and use with confidence."

I'm not promoting anything, I'm objecting to your repeated incorrect assertions about what I2C is and is not capable of. If you want to say you don't think I2C is good in this

particular case, fine. But that is not what you said (see Geeze above).

"This isn't "pushing" a non-I2C agenda/conspiracy. That would be as daft as it sounds."

Do believe in agendas (see previous responses), don't believe in conspiracies. Yes it does indeed sound daft.

"Sure, NXP recently created a marketing paper promoting multi-kilometre use (with many repeaters!) - took them 25 years to get around to it"

No agenda ? OK ?

"The video interface (built to a low cost) is still an exception, people don't use I2C for any significant distance generally. ("Generally" does not mean "only" by the way..)."

There are literally hundreds of millions if not billions of video interfaces all over the world  with cable lengths from 6 inches to 30 ft. and more in use. This is not by definition an

exception and what people "generally" (thanks for being patronizing) use has no relevance as to whether I2C works over long cable distances or not (thanks for the straw man).

One would think that a low cost build would not get all the engineering scrutiny you say is required to make it work over long distances (much less such a large range of cable

lengths).

"although I'm beginning to feel only you need this level of clarification since you tend to see things that are not really written"

This is just nonsense. All my responses are to direct quotes from your responses (some of which you seem to forget immediately after you write them, see Geeze above).

"Anyway, reaching out to my latest copy of 'Art of Electronics' - famous for practical real world guidance- the authors, Paul Horowitz and Winfield Hill too suggest (on page 1032) that typically [amongst other serial busses, I2C is] an internal serial protocol, chip-to-chip and within an instrument."

But that is not what the actual creators/maintainers and real world use says. Personally I'll stick with real world use.

"You might well wish to use I2C for long distance use but real engineers tend to ("tend to" != "only") use it conservatively for short distances because there are better long-distance protocols.."

Well except for all those real video interface engineers. It also shows up as the interface in a lot of sensor chips that real engineers use sometimes, and this is no joke, outside of enclosures.

"tend to ("tend to" != "only"

Once again, thanks for being patronizing.

"In the 4 or 5 years I've been a member here I have never had to state that and put my cards on the table, but it's tiring discussing this mundane I2C topic with you."

Perhaps then you shouldn't make statements (and then deny that you did) that are directly contradicted by facts and real world use and then defend them with straw man arguments, along with

irrelevant points and patronizing statements.

"If they ask for such advice, then it can be stated as fact that I'm giving my advice based on experience designing with it in industry, not just from using the controlled design cable that is VGA..."

Yes we should never, ever use well engineered "controlled design cables", VGA (and the much more modern DVI and HDMI just to remind you) or otherwise (\sarcasm in case you missed it).

No agenda, right ?