I2C range extender  - Page 1
Forum section: electronics / projects

author: vini_i
author_rank: Regular Contributor
timestamp: May 16, 2015, 01:31:55 am
content: 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?

author: rexxar
author_rank: Frequent Contributor
timestamp: May 16, 2015, 03:12:26 am
content: Maybe your second chip has gone bad? Either replace it, or send data in the opposite direction and see what happens.

author: technix
author_rank: Super Contributor
timestamp: May 16, 2015, 09:28:17 am
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 16, 2015, 09:37:12 am
content: 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.

author: vini_i
author_rank: Regular Contributor
timestamp: May 16, 2015, 10:11:18 am
content: Quote from: rexxar on May 16, 2015, 03:12:26 ami 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.Quote from: technix on May 16, 2015, 09:28:17 amthe 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.Quote from: nctnico on May 16, 2015, 09:37:12 amunfortunately 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.

author: technix
author_rank: Super Contributor
timestamp: May 16, 2015, 12:11:29 pm
content: 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.

author: free_electron
author_rank: Super Contributor
timestamp: May 16, 2015, 05:53:33 pm
content: Quote from: nctnico on May 16, 2015, 09:37:12 amthe 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-voltagelevels are used at Sx/Sy to avoid latching of this buffer. A regular I2C low applied at the Rx/Ry of a P82B96 ispropagated to Sx/Sy as a buffered low with a slightly higher voltage level. If this special buffered low is appliedto 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."

author: vini_i
author_rank: Regular Contributor
timestamp: May 16, 2015, 08:44:19 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 16, 2015, 09:16:22 pm
content: Quote from: free_electron on May 16, 2015, 05:53:33 pmWell then I2C would be better suited for automotive and industrial applications than RS485, CAN, etc...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.

author: free_electron
author_rank: Super Contributor
timestamp: May 16, 2015, 09:33:46 pm
content: Quote from: nctnico on May 16, 2015, 09:16:22 pmATCA 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.

author: Rerouter
author_rank: Super Contributor
timestamp: May 16, 2015, 09:44:37 pm
content: 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,

author: Fungus
author_rank: Super Contributor
timestamp: May 16, 2015, 10:41:01 pm
content: Quote from: nctnico on May 16, 2015, 09:37:12 amReally? All those people are wrong?

author: nctnico
author_rank: Super Contributor
timestamp: May 16, 2015, 11:26:52 pm
content: Quote from: Fungus on May 16, 2015, 10:41:01 pmI'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.

author: free_electron
author_rank: Super Contributor
timestamp: May 16, 2015, 11:41:05 pm
content: 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.

author: jt
author_rank: Regular Contributor
timestamp: May 17, 2015, 04:56:13 am
content: 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.

author: vini_i
author_rank: Regular Contributor
timestamp: May 17, 2015, 06:34:54 am
content: Quote from: Rerouter on May 16, 2015, 09:44:37 pmunfortunately 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.

author: Fungus
author_rank: Super Contributor
timestamp: May 17, 2015, 09:15:15 am
content: Quote from: vini_i on May 17, 2015, 06:34:54 amSometimes the simple solutions are the best.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)

author: technix
author_rank: Super Contributor
timestamp: May 17, 2015, 12:47:56 pm
content: Quote from: jt on May 17, 2015, 04:56:13 amI 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.

author: Fungus
author_rank: Super Contributor
timestamp: May 17, 2015, 01:31:52 pm
content: Quote from: technix on May 17, 2015, 12:47:56 pmWouldn't it be better to use something designed for the job?(eg. A P82B715)

author: jt
author_rank: Regular Contributor
timestamp: May 17, 2015, 02:49:25 pm
content: Quote from: technix on May 17, 2015, 12:47:56 pmThanks! 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.Quote from: Fungus on May 17, 2015, 01:31:52 pmCapacitance 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.

author: Fungus
author_rank: Super Contributor
timestamp: May 17, 2015, 02:56:23 pm
content: Quote from: jt on May 17, 2015, 02:49:25 pmI 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

author: free_electron
author_rank: Super Contributor
timestamp: May 17, 2015, 10:05:07 pm
content: Quote from: Fungus on May 17, 2015, 02:56:23 pmwell, they invented the damn thing in the first place ...( philips , now NXP )

author: LabSpokane
author_rank: Super Contributor
timestamp: May 18, 2015, 05:27:43 am
content: Quote from: vini_i on May 17, 2015, 06:34:54 amHow are the motors shielded? I actually had to build a PCB with a filter just to get the EMI under control.

author: Rerouter
author_rank: Super Contributor
timestamp: May 18, 2015, 08:12:30 am
content: 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,

author: nctnico
author_rank: Super Contributor
timestamp: May 18, 2015, 12:32:22 pm
content: Quote from: jt on May 17, 2015, 04:56:13 amThe 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.

author: Fungus
author_rank: Super Contributor
timestamp: May 18, 2015, 12:55:43 pm
content: Quote from: nctnico on May 18, 2015, 12:32:22 pmAs will a corrupted start bit on RS232.Noise is noise. The real solution is in cable shielding and checksums and ACK/NACK packets, not a different bus.PS: I2C has an ACK/NACK bit after every byte sent. The master can detect if the slave is out of sync.

author: LabSpokane
author_rank: Super Contributor
timestamp: May 18, 2015, 02:34:46 pm
content: Quote from: Rerouter on May 18, 2015, 08:12:30 amWell, that has to change or it will affect more than just the I2C bus eventually. If you care, I can post my short-term fix until I source a better-designed brushed motor.

author: nctnico
author_rank: Super Contributor
timestamp: May 18, 2015, 02:45:43 pm
content: Quote from: Fungus on May 18, 2015, 12:55:43 pmWrong! A 1us pulse on the clock of a 10kHz I2C bus will screw it up. A 1us pulse on a 9600 baud RS232 connection will go unnoticed. Remember RS232 has been designed from the start to deal with noise on long wires; I2C is not.

author: free_electron
author_rank: Super Contributor
timestamp: May 18, 2015, 03:30:29 pm
content: Quote from: nctnico on May 18, 2015, 02:45:43 pm10KHZ is not an i2c clock ! it's either 100K 400K 1M or 3.2Mthe new transceivers have noise rejecting circuitry. any pulse shorter than 1/3 of the clock is rejected. combine that with an active pull up circuit with ciurrent injecters in the modern transceivers and you end up with something pretty rugged.

author: Kalvin
author_rank: Super Contributor
timestamp: May 18, 2015, 03:32:53 pm
content: NXP Application note using P82B96 with optical isolation:http://www.nxp.com/documents/application_note/AN10364.pdf"Sending I2C-bus signals via long communications cables":http://www.nxp.com/documents/application_note/AN10658.pdf

author: Fungus
author_rank: Super Contributor
timestamp: May 18, 2015, 03:38:05 pm
content: Quote from: nctnico on May 18, 2015, 02:45:43 pmThat will depend on the RS232 chip, and ... guess what? There's I2C chips that can do exactly the same thing.You still have to add checksums and packet management in very noisy environments.Quote from: nctnico on May 18, 2015, 02:45:43 pmSure - back in the days when it was +/-12V and 1200 baud. These days it's generally TTL and much higher baud rates.

author: Fungus
author_rank: Super Contributor
timestamp: May 18, 2015, 03:44:18 pm
content: Quote from: free_electron on May 18, 2015, 03:30:29 pmThere's no lower limit. It can be 10KHz if you want it to.

author: free_electron
author_rank: Super Contributor
timestamp: May 18, 2015, 04:18:16 pm
content: Quote from: Fungus on May 18, 2015, 03:44:18 pmThere is indeed no lower limit. But, the pulse rejectors in the newer chips only work at the 'official' I2C frequencies. Ther eis a circuit that detects what speed you are running at and adjusts the noise filter accordingly. it only works in small bands