• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 35 subscribers
  • Views 283 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: Assistance with Connecting Two P82B96 Chips Over a 16' Link

Jeff Sarrazin
Prodigy 10 points
Part Number: P82B96
Other Parts Discussed in Thread: P82B715

Tool/software:

Hello,

I am attempting to connect two P82B96 chips across a link approximately 16 feet in length. I have powered the chips with 3.3V, 5V, and plan to test with 12V shortly. Using the 5V configuration, I have set up the following arrangement:

  • Source I2C: A Raspberry Pi 4B
  • Master Chip (Pins 1/7): Both SDA and SCL lines are pulled to 3.3V using 2.2kΩ resistors (I have also tried 4.7kΩ resistors).
  • Destination Device: Varies; I have tested with several devices and also with no device attached.
  • Monitoring: A Rigol DHO924S Oscilloscope.
  • Slave Chip (Pins 1/7): SDA and SCL lines are pulled to 3.3V using 2.2kΩ resistors.
  • Interconnection:
    • Master Tx (Pin 3) → Slave Rx (Pin 2)
    • Master Ty (Pin 5) → Slave Ry (Pin 6)
    • Unused pins are left floating.
    • Tx, Rx, Ty, and Ry are pulled to 5V using 750Ω resistors.
  • Source I2C Clock Frequency: 100 kHz.

From the oscilloscope, I observe a clean signal on the source I2C bus. On both chips, pins 1/7 are pulled to 3.3V at rest, and I see activity on the Tx/Rx and Ty/Ry lines. While I am not an expert in signal analysis, the signals on these links transition cleanly between 5V and 0V, with a rest state at 5V.

Issue Description:
On the slave chip's I2C side (pins 1/7), I observe a signal that closely matches the source I2C waveform. However, the voltage on the slave SDA/SCL pins never drops below 0.74V. I suspect this elevated low-level voltage is preventing the slave devices from responding, as I understand the I2C bus is expected to drop to 0V and rise to 3.3V for proper communication. On the Tx/Rx and Ty/Ry lines, the signals appear to transition correctly between 5V and 0V.

I have experimented with various configurations of pull-up resistors, as well as adding inline resistors (100Ω to 200Ω) to smooth the signals, but these adjustments have not resolved the issue.

I am considering using P82B715 chips as an alternative but would prefer to resolve the issue with the current setup if possible. Any insights or suggestions you can provide regarding the elevated voltage on the slave side and how to address it would be greatly appreciated.

Thank you for your assistance.

Best regards,
Jeff

  • 0
    Guru 316510 points

    The P82B96 indeed has a voltage offset on the I²C outputs. This is necessary to be able to differentiate between itself or some other device pulling the line low.

    Do you have any I²C device whose VIL is too low for this?

  • 0 in reply to Clemens Ladisch
    Prodigy 10 points

    I’m unsure of the exact cause, but I have tested multiple I²C devices, and when running i2cdetect on the Raspberry Pi side, no device addresses are detected on the extended bus. However, when the devices are directly connected to the Raspberry Pi, their addresses are correctly recognized.

    I must admit, I am more of an enthusiast than an expert in this area. I am trying to understand what might be preventing the devices from being recognized on the extended bus. Any guidance or suggestions would be greatly appreciated.

  • 0
    Prodigy 10 points
    UPDATE: I did change the pull up on the slave side to 1K and now the rise times more evenly match between master and slave.  Still I2CDetect will not detect the remote device .. no issues when directly connected to the Pi.  Attached scope trace link is before the modified pull ups.
    I’m sharing a trace from my test setup. Since I just got the oscilloscope, I took a photo instead of doing a digital capture—still learning the ropes here!

    Here’s how the channels are configured:

    • Yellow: Master SDA
    • Light Blue: Master SCL
    • Pink: Slave SDA
    • Blue: Slave SCL

    You can view the scope images at this link:


    Scope Trace

    https://drive.google.com/file/d/1jnzkdMBnFIdlTmg52V3jsSCNZoqUPsGk/view?usp=sharing

  • 0 in reply to Jeff Sarrazin
    Guru 316510 points

    You do not need fast rise times; it is enough that rising edges eventually reach the supply. A lower pull-up current decreases the VOL.

    The I²C waveforms look OK. Are you sure that the slave devices are powered correctly? Do you have documentation about their VIL requirements?

  • 0 in reply to Clemens Ladisch
    Prodigy 10 points

    On my test board, I moved the I²C lines directly from the slave chip to the master chip, bypassing the entire P82 setup, and everything works perfectly. I’ve tested this with several different devices, and they all work fine when connected directly.

    However, when I connect the I²C lines to the slave P82 chip, while I can capture the data on the oscilloscope without any issues (as you've seen), the devices are not recognized by the i2cdetect utility. On the scope, I noticed some ringing at the bottom of the signal. I don’t fully understand the implications of this, but it could be a contributing factor to the problem.

    Something is clearly preventing the devices from being detected, and it feels like it must be a simple issue. Unfortunately, I haven’t been able to pinpoint it yet.

    For reference, here are the relevant specifications for one of the slave devices I tested (MCP23017):

    Operating Voltage Range (VDD) VIL (Maximum) VIH (Minimum)
    1.8V to 5.5V 0.2 × VDD 0.8 × VDD
    2.7V to 5.5V 0.3 × VDD 0.7 × VDD
  • 0 in reply to Jeff Sarrazin
    TI__Mastermind 40006 points

    Hi Jeff,

    Is there a schematic you can share here? The undershoots do see prominent- are there dampening resistors being used at the outputs to help slow down the edges? 

    Regards,

    Jack

  • 0 in reply to Jeff Sarrazin
    TI__Mastermind 47128 points

    Hi Jeff,

    Based upon the VIL requirements for a MCP32017 operating at 3.3V, VIL(max) = 0.3 x 3.3 = 0.99 V. 

    THe P82B96 low level output voltage when VCC = 15V (your case 12V) for the Sx and Sy pins is: 

    At colder temperatures, VOL can reach > 1V. 

    Like Clemens was mentioning, the P82B96 has a buffered offset voltage. If you drive LOW, say close to GND voltage on the input side, the output side will be a voltage offset higher than the input. See the electrical characteristics table that I attached in this thread. VOL can reach all the way to 1V at TA = 25C for current sink up to 3 mA. 

    If I was to design this circuit with long cable, I would try to reduce the pull-up strength on the slave side. Instead of using 1k's vs 2.2k's, I would opt for something like 4.7k on the slave side to make the PU strength weaker and therefore reducing the sink current Isx and Isy which would hopefully reduce the offset voltage according to the electrical characteristics table. A lower VOL from the P82B96 would be more likely to register a valid logic LOW VIL for the MCP23017 target device. 

    Also, is there any series resistance on the slave side? 

    Jack also mentioned the undershoots. His suggestion is correct. Adding series resistance would help to dampen the effects of the undershoot.

    It also looks like there is some cross talk occurring in the scope captures. When SCL drives LOW, there appears some noise on the SDA line (I am referring to the yellow and pink waveforms. Adding series resistance would hopefully dampen this as well, but on the flip-side, adding series resistance also increases VOL, which could cause problems at the target side for it recognizing a valid logic LOW due to too high of VOL. 

    Regards,

    Tyler

  • 0 in reply to Tyler Townsend
    Prodigy 10 points

    I truly appreciate your response and the support from others here. However, I’ve decided to abandon this approach in favor of a simpler solution. I am now using RS485 for communication between my Pi and an Arduino, which functions as my I/O. This setup effectively replaces the 23017 and is cleaner and, I believe, more scalable.

    While I would have loved to get the original setup working, the challenges I faced on a 6" breadboard made me realize it would likely be a nightmare to scale over 16 to 30 feet. Despite experimenting with various pull-ups and series resistors, the devices on the slave end were never detected, even though signals were being received.

    On a positive note, this project prompted me to purchase an oscilloscope, and I can't believe I didn’t have one until now! I’m still a novice, but it’s incredibly fun to see how everything interacts.

    Thank you again for all of your kind support!

  • 0 in reply to Jeff Sarrazin
    TI__Mastermind 47128 points

    Hi Jeff,

    Glad we could help. Ask questions any time. 

    I think you made a good decision with switching to RS485 for longer distance communication. I2C was never really meant for long distances, but we do try to offer parts for those niche applications when the I2C bus is the only option. 

    Regards,

    Tyler