-
i'm working with a P82B96PWR I2C range extender. i have a set of I2C lines running next to a motor and i need to make them more immune to the motor noise. i'm trying to accomplish this with these extenders by increasing the operating voltage to 9v from 5v.
i put together two boards with these extenders to work as a pass through. one hooks up to the master the second that hooks up to the slave and the two boars are hooked together. the length of wire between them is about a meter. i've attached a schematic of the one board.
the problem i'm having is that the chips will not communicate. good data goes in one side and comes out garbled to the other side. i have a logic analyzer that i'm monitoring the data with. to help diagnosing i've reduced the system down to the bare minimum. there is a direct set of lines between the two, about a foot long. i've reduced the voltage between the two down to 5v so that i can use the logic analyzer between them. there is good data going in to chip one, good data coming out of chip one, good data arriving at chip two. but coming out of chip two there is garbage. both the clock line and the data line is uneven, random and sparretic.
i modified my design to be as close to the data sheet as possible. i changed R3 and R4 to 330 ohms. i attached 100pF capacitors to the lines that are pulled up by R1 and R2. to no avail. the data coming out of chip two is absolute trash. the master can't see anything out there and the slave doesn't understand what is coming in. i've tried checking the system with the slave connected and disconnected. i tried to reverse the boards to try and eliminate one as being bad but the same condition occurs.
any thoughts on what i have missed or what else can i check?
-
Maybe your second chip has gone bad? Either replace it, or send data in the opposite direction and see what happens.
-
I think the culprit is that you got lots of noise mixed into the single-ended signal due to the motor spitting out EMI. You can try to use two pairs of CAN or RS485 transceivers to convert the I2C lines into two bidirectional (using CAN PHY chips) or four unidirectional (using RS485 transceivers) differential pairs that can be sent over Cat5e. Differential signals are more immune to EMI and Cat5e twisted pair enhances this.
Or if you have the budget, you can try run this I2C over 4 strands of optical fiber which is 100% EMI immune. TOSLINK optical modules are dirt cheap and can operate at I2C speeds. -
I agree. I2C is about the worst choice to communicate over a wire. I would not even use it for communicating over a backplane (=PCB which connects several boards). Better use RS485 with some protocol on top of it.
-
Maybe your second chip has gone bad? Either replace it, or send data in the opposite direction and see what happens.
i have tried switching sides on the boards, making board one, board two and vise versa to determine if one is bad. exactly the same thing happens.I think the culprit is that you got lots of noise mixed into the single-ended signal due to the motor spitting out EMI. You can try to use two pairs of CAN or RS485 transceivers to convert the I2C lines into two bidirectional (using CAN PHY chips) or four unidirectional (using RS485 transceivers) differential pairs that can be sent over Cat5e. Differential signals are more immune to EMI and Cat5e twisted pair enhances this.
the motors are not spinning yet. we are doing static testing. further the same problem is duplicated on the bench as well. we are looking to possibly piggy back the off of another board that has rs485 but that complicates the system tremendously.
Or if you have the budget, you can try run this I2C over 4 strands of optical fiber which is 100% EMI immune. TOSLINK optical modules are dirt cheap and can operate at I2C speeds.I agree. I2C is about the worst choice to communicate over a wire. I would not even use it for communicating over a backplane (=PCB which connects several boards). Better use RS485 with some protocol on top of it.
unfortunately I2C is not our choice. we are talking to two Wii cameras. one is really close and has no problems. the seconds is on the other side of the robot and we have to deal with everything in between. -
This is not piggybacking I2C on RS485 or CAN, it is running I2C protocol over some alternative physical layer other than I2C's own.
I2C have the worst designed PHY ever, but the protocol is very beautifully designed (or Intel won't design the SMBus on top of that) so just by fixing its PHY can get you a long way. -
I agree. I2C is about the worst choice to communicate over a wire. I would not even use it for communicating over a backplane (=PCB which connects several boards). Better use RS485 with some protocol on top of it.
the people building ATCA and IPMI certified equipment disagree. Dell, HP , Oracle, Cisco .. you name it ...
I2C is the only bus offering hardware handshaking and collision detection (without data corruption ! )and arbitration.
That being said , you are aware of this no doubt :
"Two or more Sx or Sy I/Os must not be interconnected. The P82B96 design does not support this configuration.
Bidirectional I2C signals do not allow any direction control pin so, instead, slightly different logic low-voltage
levels are used at Sx/Sy to avoid latching of this buffer. A regular I2C low applied at the Rx/Ry of a P82B96 is
propagated to Sx/Sy as a buffered low with a slightly higher voltage level. If this special buffered low is applied
to the Sx/Sy of another P82B96, the second P82B96 does not recognize it as a regular I2C bus low and does not propagate it to its Tx/Ty output. The Sx/Sy side of P82B96 may not be connected to similar buffers that rely on special logic thresholds for their operation, such as the PCA9515A."
-
thank you so much, i was not aware and it makes perfect sense. the chip i had specked was a NXP P82B96 which the data sheet example circuits show setups that both have the lines shorted together and not. the part that was mistakenly ordered was a TI part and now looking through the data sheet there is no example of the lines shorted together.
-
Well then I2C would be better suited for automotive and industrial applications than RS485, CAN, etc...I agree. I2C is about the worst choice to communicate over a wire. I would not even use it for communicating over a backplane (=PCB which connects several boards). Better use RS485 with some protocol on top of it.
the people building ATCA and IPMI certified equipment disagree. Dell, HP , Oracle, Cisco .. you name it ...
I2C is the only bus offering hardware handshaking and collision detection (without data corruption ! )and arbitration.
Keeping I2C restricted to one circuit board is a very good rule of thumb. For starters: think about the differences (noise) in the ground levels of 2 or more boards. I read the OP is making a robot. This probably means some hefty currents will flow through the wires. That is not an environment which is kind to I2C. -
Well then I2C would be better suited for automotive and industrial applications than RS485, CAN, etc...
ATCA and IPMI are Telecoms and IT , not automotive and industrial !
Big server racks, blade type servers. they all run I2C over backplanes for system monitoring ( point of load voltage and current and temperature monitoring, sequencing and diagnostics ) has been done for years. works perfectly fine. there is no problem at all doing this as long as you meet the load requirements. I2C is very forgiving , especially at lower speeds. The newer i2c cores even have noise rejection circuitry ( clock pulses and data pulses faster than a given period are simply rejected.
-
point about the motor, is it speed controlled? if so, you may be better off using shielded cable between your extenders, as they can handle the increased capacitance,
you ground the shield to the side with the lowest ground impedance,
I've done this on multiple buses and trucks to route milli-volt signals within a few cm of an ignition coil and alternator with no issues, your only concern will be capacitance from the shielding, -
I agree. I2C is about the worst choice to communicate over a wire.
Really? All those people are wrong?
-
I've seen nothing but problems when people use I2C as a bus from one PCB to another. If the communication isn't critical or very slow so you can add plenty of HF filtering and miss a message every now and then you could get away with it but still you'll need to watch out for shifts in ground levels and noise immunity. It is very easy to shoot yourself in the foot.I agree. I2C is about the worst choice to communicate over a wire.
Really? All those people are wrong? -
Then they are clueless and aren't doing it right. That's not the fault of I2C. You can fuck up a CAN network very easily as well. (actually CAN neds to have the right termination , the right bus topology and requires matched impedance traces !
I2C is sucessfully being used on large 24 inch rack systems , distributed over backplanes without problems.
-
The benefits of I2C over other protocols with more robust hardware layers are hard to ignore. I use bus capacitance isolators and bus accelerators liberally in my designs and haven't had issues routing I2C across backplanes and wire harnesses. My components of choice are the Fairchild FXMA2102L8X and Linear Tech LTC4311ISC6.
Of course different applications will have different challenges. I've heard of using an LVDS hardware layer for I2C, but don't have a reference schematic handy. -
point about the motor, is it speed controlled? if so, you may be better off using shielded cable between your extenders, as they can handle the increased capacitance,
you ground the shield to the side with the lowest ground impedance,
I've done this on multiple buses and trucks to route milli-volt signals within a few cm of an ignition coil and alternator with no issues, your only concern will be capacitance from the shielding,
unfortunately due to a time crunch we are ditching the extenders. the motors are speed controlled, they are brushed dc motors with H-bridge controllers. plan B was to replace the wiring with shielded wiring. plan C is to piggy back a second controller off a controller on a rs485 line near buy to do the I2C comms locally.
we have implemented plan B and so far it is working. -
plan B was to replace the wiring with shielded wiring.
Sometimes the simple solutions are the best.
we have implemented plan B and so far it is working.
It's also worth looking at the rising edges of your signal with a 'scope to make sure your pullups are doing their job properly. Poor pullups can cause problems in noisy environments.
(try smaller resistor values, put the resistors in different places ... fiddle around until you get nice short rise times on the signal)
-
The benefits of I2C over other protocols with more robust hardware layers are hard to ignore. I use bus capacitance isolators and bus accelerators liberally in my designs and haven't had issues routing I2C across backplanes and wire harnesses. My components of choice are the Fairchild FXMA2102L8X and Linear Tech LTC4311ISC6.
Of course different applications will have different challenges. I've heard of using an LVDS hardware layer for I2C, but don't have a reference schematic handy.
I don't think the I2C over LVDS is too different from I2C over RS485: split the bus up into two pairs of unidirectional lines with P82B96, and use a pair of RS485 transceivers to send I2C over 4 twisted pairs. The 4 twisted pairs are usually Cat5e with RJ-45, probably TIA/EIA-568 pin out to reuse existing Ethernet cables. -
I don't think the I2C over LVDS is too different from I2C over RS485: split the bus up into two pairs of unidirectional lines with P82B96, and use a pair of RS485 transceivers to send I2C over 4 twisted pairs. The 4 twisted pairs are usually Cat5e with RJ-45, probably TIA/EIA-568 pin out to reuse existing Ethernet cables.
Wouldn't it be better to use something designed for the job?
(eg. A P82B715)
-
I don't think the I2C over LVDS is too different from I2C over RS485: split the bus up into two pairs of unidirectional lines with P82B96, and use a pair of RS485 transceivers to send I2C over 4 twisted pairs. The 4 twisted pairs are usually Cat5e with RJ-45, probably TIA/EIA-568 pin out to reuse existing Ethernet cables.
Thanks! I didn't know about that IC. I'll keep it in mind if I'm faced with having to do any particularly long runs.
Wouldn't it be better to use something designed for the job?
(eg. A P82B715)
Capacitance isolaters like the P82B715 are indeed the better solution up until a point, but won't be able to achieve as long of runs as a properly terminated differential pair will. Looks like the P82B96 is designed with I2C in mind judging from the first-page app note on the TI datasheet.
-
Capacitance isolaters like the P82B715 are indeed the better solution up until a point, but won't be able to achieve as long of runs as a properly terminated differential pair will. Looks like the P82B96 is designed with I2C in mind judging from the first-page app note on the TI datasheet.
I picked a chip at random from google...
There's a few different chips which are designed specifically for buffering I2C (TI has a whole category for them).
A lot of them are standard parts which are made by other people, too, eg. NXP is big on I2C devices
-
NXP is big on I2C devices
well, they invented the damn thing in the first place ... ( philips , now NXP )
-
unfortunately due to a time crunch we are ditching the extenders. the motors are speed controlled, they are brushed dc motors with H-bridge controllers. plan B was to replace the wiring with shielded wiring. plan C is to piggy back a second controller off a controller on a rs485 line near buy to do the I2C comms locally.
we have implemented plan B and so far it is working.
How are the motors shielded? I actually had to build a PCB with a filter just to get the EMI under control. -
the motor is not shielded, the wiring they are using for there communications nearby to the motors are, speed controlled motors are some of the loudest electrical noise sources i am aware of,
-
The benefits of I2C over other protocols with more robust hardware layers are hard to ignore.
The main problem with using I2C over longer distances / in dirty environments is that it is a synchronous bus. Synchronous busses are pretty bad over long distances / in dirty environments because the clock needs to arrive 100% clean. One spike on the clock line will screw up an entire message! Asynchronous protocols (like CAN or UART) are usually better protected against glitches.