USB is not based on I2C. USB has unique electrical and protocol 
characteristics invented for USB.

"Neil Kurzman" <nsk@mail.asb.com> wrote in message 
news:414C515B.AE18C2D4@mail.asb.com...
>
>
> Colin MacDougall wrote:
>
>> Has anyone any experience of running an I2C bus from
>> a PCB to a remote I2C device ? I am thinking of
>> connecting a remote Dallas Semiconductor I2C temperature
>> sensor IC to a micro over a length of 4 or 5 metres of
>> wire. The temp sensor would be fixed to the ceiling to
>> measure room temperature and the micro would be in a
>> monitoring / control box on the wall.
>>
>> Could I run this at the typical 400 KHz clock speed with
>> a decent bit of screened cable ?
>>
>> Colin
>
> Look at the USB specs (USB.org)  the USB protocol is built on top of
> I2C.
> By the way SM Bus is too, but I don not think that is designed to go off
> board very far.
>
> 

Neil Kurzman <nsk@mail.asb.com> wrote:
> Colin MacDougall wrote:

[...]
> > sensor IC to a micro over a length of 4 or 5 metres of
[...]

> Look at the USB specs (USB.org)  the USB protocol is built on top of
> I2C.

... and has a maximum allowed cable length of 5 meters between active
components.  Which likely means that it's unsuitable for the case at
hand.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Colin MacDougall wrote:

> Has anyone any experience of running an I2C bus from
> a PCB to a remote I2C device ? I am thinking of
> connecting a remote Dallas Semiconductor I2C temperature
> sensor IC to a micro over a length of 4 or 5 metres of
> wire. The temp sensor would be fixed to the ceiling to
> measure room temperature and the micro would be in a
> monitoring / control box on the wall.
>
> Could I run this at the typical 400 KHz clock speed with
> a decent bit of screened cable ?
>
> Colin

Look at the USB specs (USB.org)  the USB protocol is built on top of
I2C.
By the way SM Bus is too, but I don not think that is designed to go off
board very far.

Colin MacDougall <colin@blueyonder.co.uk> wrote:
: Has anyone any experience of running an I2C bus from
: a PCB to a remote I2C device ? I am thinking of
: connecting a remote Dallas Semiconductor I2C temperature
: sensor IC to a micro over a length of 4 or 5 metres of
: wire. The temp sensor would be fixed to the ceiling to
: measure room temperature and the micro would be in a
: monitoring / control box on the wall.

: Could I run this at the typical 400 KHz clock speed with
: a decent bit of screened cable ?

The Dallas/Maxium 1 wire interface is more suited for this. You can use a i2c 
to 1wire interface that Maxium just released and use a 18S20 1 wire temp
sensor. They make a RS232 to 1 wire interface also. 

1 wire info: http://www.1wire.org/ and http://www.maxim-ic.com/

I have a 60' or so cable run to several of my weather sensors at home that
uses the 1 wire interface.

See:
http://pages.sbcglobal.net/greghol/wx/weather.html

-- 
Greg Holdren
greg (dot) holdren (at) <initials of company> (dot) com

"Bob" <SkiBoyBob@excite.com> wrote in message 
news:10kma2ff3su2o80@corp.supernews.com...
>> Here's a photo of that HVAC controller:
>> http://www.synthcom.com/~nb/Controller3.jpg
>> Yes, I'm aware that the power supply is a big ugly hack. ;-) It has since
>> been replaced with a switcher...
> Hi Neil,
> I think the link you meant was:
> http://www.synthcom.com/~nb/controller3.jpg

No! I meant:

http://www.synthcom.com/~nb/controller3.JPG

> PS: several of your stinky pics don't show up... is the images directory 
> in
> the right place?

That whole directory is a cobwebsite ....

-->Neil 

> Here's a photo of that HVAC controller:
>
> http://www.synthcom.com/~nb/Controller3.jpg
>
> Yes, I'm aware that the power supply is a big ugly hack. ;-) It has since
> been replaced with a switcher...
>
> -->Neil
>
Hi Neil,
I think the link you meant was:
http://www.synthcom.com/~nb/controller3.jpg
(lower case "c")
The Fry's receipt makes it look so much more real ;-)

PS: several of your stinky pics don't show up... is the images directory in
the right place?

Bob

"Hans-Bernhard Broeker" <broeker@physik.rwth-aachen.de> wrote in message 
news:2r0ku2F13d79tU1@uni-berlin.de...
> Colin MacDougall <colin@blueyonder.co.uk> wrote:
>> I don't need the temperature measurements that fast ( 1 per minute
>> would do ) but I intended the I2C bus to also connect an eeprom
>> device to record those measurements.
> In that case, I would think twice whether it's really a good idea to
> connect two devices with such rather incommensurable requirements
> regarding data rates, distance and EMI behaviour as an EEPROM right
> there on the board, and temperature sensor elsewhere in the room to
> the same data line.  If ever there was a reason to have multiple data
> ports on a single CPU/controller, I would think you've just about
> given a textbook example for it.
> [snip]
> Unless you're absolutely starved out of free pins and/or free space on
> the board to use for a line protocol converter between I2C and
> whatever you'll use to driver that temperature sensor, I would think
> keeping these two device on separate busses would get you rid of quite
> a number of worries, for acceptable cost.

Colin, Hans is offering some very, very good advice, here. I'm certain 
you've got a couple of I/O pins to spare - definitely do what he says.

In my HVAC controller, I get several glitches on the I2C bus a day. I'm 
controlling a 12 amp @ 240 volt heat pump, a 9 amp furnace, 20 amp resisitve 
heating, and a backup generator, and when the heat pump shuts down, the 
collapse of the inductive field does generate a spike on the I2C bus, which 
causes the DS1621s to get scrambled (requiring them to be reset). I'm not 
sure if your environment is as noisy, but I would *NEVER* trust an E^2 write 
on the same set of lines as the temperature sensors.

Here's a photo of that HVAC controller:

http://www.synthcom.com/~nb/Controller3.jpg

Yes, I'm aware that the power supply is a big ugly hack. ;-) It has since 
been replaced with a switcher...

-->Neil 

Colin MacDougall <colin@blueyonder.co.uk> wrote:

> I don't need the temperature measurements that fast ( 1 per minute
> would do ) but I intended the I2C bus to also connect an eeprom
> device to record those measurements.

In that case, I would think twice whether it's really a good idea to
connect two devices with such rather incommensurable requirements
regarding data rates, distance and EMI behaviour as an EEPROM right
there on the board, and temperature sensor elsewhere in the room to
the same data line.  If ever there was a reason to have multiple data
ports on a single CPU/controller, I would think you've just about
given a textbook example for it.

Questions to check:

*) can you really afford having communication with that EEPROM
disturbed by EMI effects collected by 5 meters of cabling?

*) is it even remotely convenient to have to stop access to the EEPROM
in order to access the temperature sensor?

Unless you're absolutely starved out of free pins and/or free space on
the board to use for a line protocol converter between I2C and
whatever you'll use to driver that temperature sensor, I would think
keeping these two device on separate busses would get you rid of quite
a number of worries, for acceptable cost.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

"Hans-Bernhard Broeker" <broeker@physik.rwth-aachen.de> wrote in message 
news:2r06ijF1442t9U2@uni-berlin.de...
> Colin MacDougall <colin@blueyonder.co.uk> wrote:
>> Has anyone any experience of running an I2C bus from
>> a PCB to a remote I2C device?
>
> No experience, but a caveat: that's not at all the kind of operation
> I2C is designed for.  It may work, sure, but you should be aware
> you're stretching a design quite a bit beyond its intentions.
> Problems are almost guaranteed.
>
>> I am thinking of connecting a remote Dallas Semiconductor I2C
>> temperature sensor IC to a micro over a length of 4 or 5 metres of
>> wire.
>
> Their "1-wire" technology might be preferrable for that usage.
>
>> Could I run this at the typical 400 KHz clock speed with
>> a decent bit of screened cable ?
>
> Even if you could, why would you want to?  I would think ambient
> temperatures in a room change at speeds on the order of at most 1
> degree/minute, so anything faster than one reading per second per
> sensor would be complete overkill, and one reading every minute might
> still be perfectly enough.  You don't need anything as fast as 400 kHz
> for that.
>
> -- 
> Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
> Even if all the snow were burnt, ashes would remain.

I don't need the temperature measurements that fast ( 1 per minute would 
do )
but I intended the I2C bus to also connect an eeprom device to record those
measurements. When the measurements have to be retrieved then the full bus
speed would be desirable. A fast/slow clock select would of course be the
solution but also mean more software overhead.

Colin 

Colin MacDougall <colin@blueyonder.co.uk> wrote:
> Has anyone any experience of running an I2C bus from
> a PCB to a remote I2C device? 

No experience, but a caveat: that's not at all the kind of operation
I2C is designed for.  It may work, sure, but you should be aware
you're stretching a design quite a bit beyond its intentions.
Problems are almost guaranteed.

> I am thinking of connecting a remote Dallas Semiconductor I2C
> temperature sensor IC to a micro over a length of 4 or 5 metres of
> wire.

Their "1-wire" technology might be preferrable for that usage.

> Could I run this at the typical 400 KHz clock speed with
> a decent bit of screened cable ?

Even if you could, why would you want to?  I would think ambient
temperatures in a room change at speeds on the order of at most 1
degree/minute, so anything faster than one reading per second per
sensor would be complete overkill, and one reading every minute might
still be perfectly enough.  You don't need anything as fast as 400 kHz
for that.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.