This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

P82B96: What buffer/repeated can I use between the Sx/Sy pins of two P82B96?

Part Number: P82B96
Other Parts Discussed in Thread: TCA9803, TCA9517

Summary:

I need to connect the Sx and Sy pins of two P82B96 I2C re-drivers together.

I've tried two different I2C translators and neither worked.

What buffer/translator will work?

The green line represents the I2C network I'm trying to create across the chain of boards:

This is the circuit from the datasheet I used as reference for my design:

Setup:

There is 1 Master in the system, the MCU on the Controller board. And everything else is a Slave.


My system has 1 Controller board, and up to 20 Power boards, all wired together in series in a long chain.

The Controller communicates over long distance I2C, using the P82B96 Tx/Rx & Ty/Ry, to the first Power board in the chain, where it communicates with several I2C devices on board. The Controller only powers on and communicates with 1 Power board at a time. Devices on each Power board are turned on/off with a separate, non-I2C control mechanism. But the P82B96 chips are always powered.

Each Power board is meant to re-transmit the I2C signals it receives to the next Power board in the chain, using two P8296 chips; one for processing the long distance I2C coming in, and another to re-transmit the long distance I2C going out.

So if the Controller wants to talk to Power board #2 in the chain, the long distance I2C goes into Power board #1's first P82B96 chip, and is converted to on-board I2C. The on-board I2C then goes into the second P82B96 chip to be re-transmitted over long distance to the second Power board.

The datasheet says the two P82B96 chips cannot be connected as I have connected them. So I've installed 2 different I2C buffers/repeaters to try to fix it, but they haven't worked. The VOL from the P82B96 only goes down to about 1V, but the VIL threshold is 0.6V.

Is there anyway to make this work as intended?

Thank you,

Mike

  • Almost all I²C buffers have restrictions that prevent some of their ports from being connected to each other.

    If the capacitance of a single cable is not above 400 pF, then you could use buffers like the TCA9803, while ensuring that only A and B sides are connected.

    Alternatively, create one large I²C bus, with each board branching off. If the total capacitance is too high, consider using RS-485 instead.

  • Hi Mike,

    In general applications using the P82B96 I2C bus extenders, we generally only see one long cable followed by two larger bus nodes connecting multiple i2C devices on the Sx/Sy pins of each device. I haven't seen this type of application where there are longe I2C connections in series with multiple P82B96 devices. 

    Your current setup involves the P82B96 followed by another P82B96 for long cable extension, followed by an I2C buffer TCA9803. In general, the TCA9803 has specific requirements on the B-side making this device difficult to use in application. Things like IEXTI/O requirements and removal of pullups on the B-side entirely are difficult to implement in most I2C applications. 

    About how long are these cables lengths between each power unit? Generally speaking, from a PCB trace perspective we can estimate parasitic trace capacitance to yield about 3pF / inch. There are also cable measurements that have some pF/meter, I have seen some CATe5 cable used having a 10-50pF / meter measurement for example. Do you truly need to buffer between power units that have a capacitance of >400pF? 

    A device that I would recommend in place of the TCA9803 would be the TCA9517. You can connected this buffer in series connecting A-side to B-side in alternating fashion. With this many buffers in series for your application, I would expect some very long propagation delays in your system. 

    As Clemens already mentioned, an application like this one could use another protocol that is suitable for long distance nodes such as RS-485. I know that replacing your I2C system with RS-485 is probably your last option, but it does seem like it would solve this problem much easier using a differential setup. 

    Regards,

    Tyler