I2C long cable test

[Damien P]

I've been testing out connecting microcontrollers with long wires.
I've been using 3.5m lengths of speaker wires (the conductors are
about 0.1mm across), connected to the circuits with alligator clip
cables, so it's pretty bad from a transmission line point of view.

I connected one slave with one length of wire, and everything worked
fine. I connected the clock line to the second slave in series,
things still worked. When I connected the data line, the
communications stopped working.

Normally the clock signal is only working when the master is sending
or receiving data. When the bus stops working, the signal is
constantly going high and low. Perhaps capacitance/reflections/
Fukushima power plant radiation in the wire is making the master think
that it's getting a response, and it's getting confused. A similar
thing happens to the data line.

When I connected the wires in parallel, the circuit didn't work at
all. I guess this is the same situation as when capacitors are
connected in parallel.

This result doesn't look very promising, but this is probably a worst
case test. Hopefully some cable with a lower capacitance will work a
bit better. It looks like we'll need to do some more testing.

3.5m of cable is a reasonable length - I can't imagine our data lines
will be more than about 6m long. Cat5 apparently has a maximum
capacitance of 200pf per 100m, and i2c permits up to 400pf. I don't
have a any way of measuring the capacitance of my speaker wires. The
serial vs parallel observation is interesting too, and something we
can experiment with.

[Ken]

I have run I2C over very long wires (telephone cable), and over an optic-fibre link for high voltage isolation.
It will be the capacitance that is killing you.
If you are able to change the I2C clock speed, try running at a lower speed.
But that is not the whole story.
Have a look at the specs for the I2C bus. The clock transition width is specified as 1uS or less.
You can run I2C as slow as you want (I've done it via the cassette audio output from a Tandy Color computer).  But the clock transitions have to be fast.  I fixed that by putting a schmitt trigger at the clock inputs on chips.
(Why the chips don't have a schmitt input on the clock line beats me.)

The lowest capacitance wire might be something like 300ohm TV ribbon?
But since the signals are relative to ground, what are you using for a grounds connection?
You'll need 3 wires, 4 if you are passing +5v to the peripherals as well.

Ken.

--
You received this message because you are subscribed to the Google Groups "HackerSpace - Adelaide, South Australia" group.
To post to this group, send email to hackerspac...@googlegroups.com.
To unsubscribe from this group, send email to hackerspace-adel...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/hackerspace-adelaide?hl=en.

[Damien P]

Thanks for those tips, Ken.

I didn't mention that this test is for the lantern...

My testing was just on a few breadboards sitting next to each other
with solid insulated wire connecting the power (the different devices
weren't physically separated). The lantern has pretty thick wires
supplying power and ground so hopefully power distribution won't be a
problem.

I used the speaker wire knowing the capacitance would be high. The TV
antenna wire isn't a bad idea, and we can test different types of wire
before we connect everything to the lantern. The i2cbus.org site
suggests putting the power and/or ground between the data wires, but
we probably need the thickest wire we can find for power distribution
and the thinnest for the data.

That's a good point about the transition time being the critical
parameter, I didn't know that. I'm not sure what speed I was
operating the bus at - I guess it's whatever the AVR's default is. I
could see the transition on the DSO Nano, so it must have been less
than 1us.

[Ken]

Can I ask what is maybe a dumb question....
Why isn't the lantern simply a matrix of wires all running back to a central point with lots of X & Y driver ports? 
Say a bunch of binary to single port demultiplexors, driven by an Arduino or whatever.
Surely then, voltage drop, speed, reflections etc would be pretty well irrelevant?

Ken.

--

[Steven Pickles]

Did you try with the cat5 cable you were working with at the hack session?

pix

On 17 April 2011 22:02, Damien P <ath...@gmail.com> wrote:

--

[Damien P]

On Apr 17, 9:40 pm, Ken <k...@waggies.net> wrote:
> Why isn't the lantern simply a matrix of wires all running back to a central
> point with lots of X & Y driver ports?

Good question! This is essentially how we're driving the rows - we're
using shift registers and FETs.

The columns are driven by the TLC chips, so we can control the
brightness. I guess we could perform the switching in software to
provide an "analogue" output, assuming we can drive whatever
demultiplexer we use at that speed. I guess we could move the TLCs so
they're near the controller. Any capacitance/reflections/etc will
show as ghosting or similar, but at least it won't be random
flickering like we have now.

There was talk of using an FPGA to drive the whole thing...

On Apr 17, 9:41 pm, Steven Pickles <thatpix...@gmail.com> wrote:
> Did you try with the cat5 cable you were working with at the hack session?

No, I didn't. I couldn't get the socket from the motherboard working
(I wouldn't have thought it would be difficult, but there you go), and
the plugs aren't very easy to hack. I think there's some bare cable
at my parents' place which I could get on the weekend. I could cut
the plugs off; the cables aren't very expensive.

[Ken]

Unless you want to buy a 300 metre roll of cat5 cable, I've found the cheapest way to get it is as a 30 metre cable with plugs on.
But beware, cat5 ain't just cat5 (to paraphrase an old ad).

I have a webcam in a birdnest at home, cabled to a PC using USB-extenders each end of cat5 cable. (It results in about USB-1.)
I bought a 30M cable from MSY, and the webcam didn't work over it.  Other cable I had (not cat6) was OK.
Now I look for bright blue sheathed stuff, rather than grey.

-I haven't investigated why the MSY stuff didn't work.  It may be as simple as thinner wire. Some webcams don't work over a 30m link (eg Microsoft ones) because they draw too much current.  (I can kill the current webcam by turning on the LEDs in it.)

If you want minimum capacitance, I wonder whether cat6 might be better?

Ken.

[Damien P]

I've done some experiments with i2c over 2 metres of cat5 cable.
Again, the circuit worked fine when connected with short cables, but
when connected with the longer cable things didn't work so well.

In the accompanying image [1] (note the traces are in different time
scales - apparently the DSO can "store" signals, but I can't work out
how to access them), the light blue horizontal bars are roughly where
the i2c spec says the signal has to reach. With the shorter cable, the
signal moves into the limits of the spec, but with the longer one, the
signal transitions too slowly to change state.

It's not all bad news though. It looks like the signal only missed the
thresholds because of the low slew rate. One problem is that i2c never
drives the line high - it just leaves the line float back to the high
state, the results of which are easily seen on the attached image. If
we chose a serial protocol instead - one which actually drives the
line high AND low - we may not have this problem.

I'm not sure whether to choose SPI or asynchronous serial, the latter
has the advantage that we don't need a clock line and might get away
with one data line. If we use the internal 8MHz oscillator on the AVR,
we can run asynchronous serial at about 500kbit/s (you can actually go
faster, but you risk synchronization problems on the receiver). SPI
should be able to go faster, of course slew rates may limit our speed.

And if we have voltage problems, we might be able to use a RS232 or
RS485 transceiver on the sender, and hopefully get away with a few
resistors on the receiver.

I guess my next experiment is to repeat with asynchronous serial and
see if that works better over the longer cable, and if that doesn't
work, then try a serial tranciever.

1: http://www.hackerspace-adelaide.org.au/wiki/File:Peel_St_Lantern_i2c_test_results.jpg

[Ken]

Try a pullup resistor.

Ken.

[Jonathan Pearce]

Buffer circuit? There's any number of ICs that bring poor signals to TTL.

[Ken]

There are buffer chips specific to I2C.

Ken.

[Damien P]

On Apr 25, 9:07 pm, Ken <k...@waggies.net> wrote:
> Try a pullup resistor.

I gave that a shot, but the value seemed to be rather sensitive. Too
low and it would stop all communication, too high and it made no
difference.

Come to think of it, I can't explain why a resistor would stop ALL
communication (unless the value is too low); maybe I should try again.

[Thomas Sprinkmeier]

On 27 April 2011 13:14, Damien P <ath...@gmail.com> wrote:
> On Apr 25, 9:07 pm, Ken <k...@waggies.net> wrote:
>> Try a pullup resistor.

Or something like a "P82B715PN I2C bus extender" or a "P82B96 Dual
bi-directional bus buffer".

I've used one of them (the P82B96?) to go from 5V to 3.3V I2C. The
application note has schematics for all sorts of buffering circuits
for long-haul I2C.
I've got the PDFs if you want them.

Thomas

[Damien P]

I found a list of some differential line drivers (I'm posting them
here so I can throw out the receipt I wrote them on):

- DS8921
- DS9637/DS9638
- AM26LS31
- 75176

Other options might be RS232, RS485, RS422 or CAN (apparently STM8
microcontrollers will use CAN).

[Damien P]

I tried again using asynchronous serial instead. I chose that because
we'll only need 1 wire, whereas SPI would need 2. The results are
more encouraging:

http://www.hackerspace-adelaide.org.au/wiki/File:Lantern-serial-comms.JPG

I'll have to test the fanout and cable length now.

[Damien P]

I sent the signal through a cat5 wire 7 times, and the signal came out
the other end fine. It's probably not the best test though, because
the cross-talk between the wires might enhance the signal in this
case.

http://www.hackerspace-adelaide.org.au/wiki/Peel_Street_Lantern#Using_a_serial_protocol

[Jonathan Wheare]

Thanks for the update Damien. What baud rate is this running at? From
the oscilloscope it looks to be around 110k Baud at TTL voltage levels.

J.

[Damien P]

On May 15, 7:06 pm, Jonathan Wheare <jonathanwhe...@gmail.com> wrote:
>
> Thanks for the update Damien.  What baud rate is this running at?  From
> the oscilloscope it looks to be around 110k Baud at TTL voltage levels.
>

That's right, it's running at 115200. I should try it at higher
speeds. If we have a bare AVR at the receiving end (ie. without a
crystal) we'll be limited to the internal 8MHz clock and the clock
won't be terribly accurate, so it will be interesting to see how fast
the serial communication will run at.

AVRs have a neat "multi-slave" mode on their serial ports, where you
won't get interrupts unless the received character has an "address
bit" set. The idea is, when the address bit is set, you see if it's
addressed to you; if not, you set a flag that says you want to ignore
characters without this bit. This might be useful when addressing the
8 slave chips around the lantern.

[Damien P]

Last night I tried operating the line at 500kbps, and everything
worked fine. I even tried connecting an AVR without a crystal as the
master and the slave, and that worked fine too. That might have been
more arse than class though - according to the datasheet, the internal
oscillator can vary by 10%, but operating a serial line at that speed
may only vary by 3-4%. We could either play it safe and use AVRs with
crystals (Arduino Pros?) or add software to adjust the oscillator if
we're not getting useful input.

It also didn't occur to me previously that I can produce debugging
output on the slave on the same serial port that's receiving data,
which means I can perform debugging without an Arduino Pro. I tried
that out with a plain Arduino and that worked fine - I was able to see
the debugging output via the USB cable, and receive data on the RX pin.

[Geordie Millar]

Or you could solder a crystal and two capacitors to the bottom of the Arduino board, and change the boards.txt in Arduino to set the fuses correctly to use them.
A but hackish, but then again, what are we? :P