[TriEmbed] I2C range extension

[Charles West]

As usual, really good information (thanks).

The big driver for looking into I2C as a solution is that CAN requires the
impedance matching at each end of the bus and doesn't approve at all of
using a star topology (also I2C based solutions look to be about 1/2 or
less of the cost).  I don't really know how to make a plug and play
tree/star topology if the impedance matching needs to be at each "longest"
end of the bus.

In an ideal world, we would be able to compensate for the decreased
reliability of I2C with more error detection at a higher level.  What I
seem to be hearing, however, is that unless we can drive at a really high
voltage in a none noisy enviroment, there are likely to be enough problems
to make it impractical.

It would seem that despite the high cost and overhead of CAN, the majority
census is that it and RS485 are the way to go to deliver the reliability
that is deemed necessary for robotics.

If I may ask, do you know of any good solutions for the impedance matching
problem?  We could potentially put higher resistor values distributed at
each termination point in the star networks, which should help with
ringing.  In that case, it is hard to control the total bus impedance
values though.

We could alternatively use pairs of transistors to electrically
enable/disable resistors on the star connection points, but that doesn't
seem terribly efficient either.

Thanks again,
Charlie

P.S.
Nice tip on Access.Bus.  That is really similar to what we are trying to
do, but our focus is more on plug and play robotics.

On Wed, Sep 30, 2015 at 3:04 PM, Rodney Radford via TriEmbed <
triembed at triembed.org> wrote:

> I used I2C to control about a dozen salt water aquariums several years
> ago.
>
> This involved a single PC bit-banging I2C out a parallel port (so was
> slow) to a temperature sensor in each of the aquariums (some 30' away),
> sending status out to a a couple 2x16 and 4x16 displays (I2C serial ->
> parallel -> LCD parallel interface), and controlling the heaters.
>
> This was for an outdoor, unheated, uninsulated building where the water in
> the salt water aquariums had to be kept within a fairly narrow range.  We
> monitored the temperature of the tanks and the external temp and would
> start the heaters in the water when we notice the temp dropping.  This
> replaced a mechanical temperature setup where the heaters would turn on
> once the water got too cold, but by that time, the thermal mass of the
> water prevented it from heating fast enough.
>
> Now all of this would be replaced with a couple Arduinos, one devoted to
> each tank, and a multi-drop serial bus to report back to the PC, but this
> was back about 20 years ago.
>
> This worked with no problems for the several years i worked with it.
>
> A few things we did:
> * twisted pair
> * I2C range extenders with 12v pullups
> * was not a noisy environment (outdoor building with only a single power
> drop and no other electrical devices)
>
> This was far enough back that you couldn't even buy the I2C devices in low
> quantities, so companies like Pure Unobtanium sprung up (Ed Nisley's
> company - previous author in Circuit Cellar Ink, and past Triangle Amateur
> Robotics member) would buy parts in the minimum quantity and sell to
> hobbyists.  Unfortunately by the time he would burn through enough stock to
> break even, they would be available from other suppliers for less.
>
> Also check out AccessBus - it was based on I2C and was designed to be a
> desktop peripheral interface.  Unfortunately it was not adopted and USB has
> since taken over this market.
>
> So the short of it - yes, you can use I2C for longer distances in some
> circumstances.
>
>
> On Tue, Sep 29, 2015 at 10:03 PM, Charles West via TriEmbed <
> triembed at triembed.org> wrote:
>
>> Hello,
>>
>> Thanks again for all the good discussion on electrical connectors.
>>
>> We're still debating some of the specifics for the CANInstall and/or
>> I2CPotential protocols.  One of the big things up in the air is how
>> reliable I2C is and how long the range can be.
>>
>> My impression is that having a I2C bus of more than a meter or two is
>> considered pushing your luck.  However, there seem to be range
>> extender/repeater chips available that promise rather drastically improved
>> range (such as the P82B715).
>>
>> If I may ask, what is the longest I2C bus you have built/seen?
>>
>> How has your experience been in terms of reliability?
>>
>> What sort of bus speeds do you tend to use?
>>
>> The bus speed is driven by the master, so theoretically you could have a
>> sub-hertz baud rate?  Does this mean that you could get a really long range
>> with a super slow baud rate or are the edges not sharp enough to be
>> detected?
>>
>> Thanks,
>> Charlie
>>
>> _______________________________________________
>> Triangle, NC Embedded Computing mailing list
>> TriEmbed at triembed.org
>> http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
>> TriEmbed web site: http://TriEmbed.org
>>
>>
>
> _______________________________________________
> Triangle, NC Embedded Computing mailing list
> TriEmbed at triembed.org
> http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
> TriEmbed web site: http://TriEmbed.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20150930/3dadcb93/attachment.htm>