TRSF3238E: Coupling between DOUT and RIN

Hi Donald,

I suspect the coupling mechanism is capacitive (especially since the amplitude increased when a cable was introduced), although if you could provide oscilloscope captures showing the coupled noise it may help to better understand whether this is really the case. I can't think of any particular failure mode within the IC that could cause what you've described. You could check for IC failure by swapping the part with a new one, though. (You may also want to observe the V+ and V- rails of the problem IC to make sure they are stable - if not it could give an indication of issues with the IC or may highlight another noise coupling path.)

At what data rate is your RS-232 link running? TRSF3238E is a relatively fast device since it was intended to support up to 1000 kbps. If that high rate is not needed, though, you could select a different transceiver with slower DOUT slew rates, which would reduce the degree of capacitive coupling in this system. (You could also slow down the existing device's slew rates via addition of R/C filtering on DOUT, although this will limit data rates as well. Similarly, I would expect additional load capacitance on RIN to reduce the magnitude of the coupling at the expense of receiver input bandwidth.)

Regards,
Max

Hi Max,

Many good points in your reply. I don't have a scope shot to share at the moment but the noise spikes are characterized by a quick rise (~100ns), followed by a slow decay (~1-2us). My maximum data rate is rather modest, 115k. Up 'til now, though I've been operating the test equipment at 300 baud, so the failures are definitely edge related rather than data-rate related.

I did some experiments and found I could eliminate the spikes on RTS (Rin), or at least keep them under the +/-300mV threshold, by hanging a 170nF cap on RXD (Dout). I haven't tried an RC combination yet. It changes my Dout rise time from about 100ns to 60us. I haven't yet considered whether this can work at 115Kbaud.

Does TI make a slower Dout 4+, Rout 3+ transceiver in a SSOP-28 package?

Thanks for your help!

Hi Donald,

The MAX3238E would be a pin-for-pin replacement to TRSF3238E with substantially lower output slew rate (since it was designed for maximum baud rates of 250 kbps). Based on the waveform you described (with fast rise times and slow decay), replacing your transceiver with this device should help. (In case you have trouble finding MAX3238E, another name for the device is TRS3238E. Note that this is the same as the part number as the one you currently use, just without the "F." The "F" in this case denotes "fast.")

Regards,
Max

Slower slew is better.  I could live with a 115-120K part but they all seem to run at 5V.

I was comparing the TRS3238 and the MAX3238E.  They seem to have identical timing and slew specs but the TRS3228 is rated at 250kbits/sec and the MAXC3228E is rated at 400kbits/sec.  What is the difference between the two?

Best regards,

 -Donald

Donald,

Those designations may be more a function of marketing concerns than technical ones. The maximum bit rate that can be supported depends on the slew rate and how much "settling time" is desired for each bit before the next transition is expected to begin. In this case the slew rates of both the devices are the same, yet one device is specified more conservatively to assume more settling time for each bit.

In this case TRS3238 seems to have been specified to match the previous-generation MAX3238 device (from 1999), most likely to make it clear that it could be used as a drop-in replacement. The TRS3238E and MAX3238E devices were based on TRS3238 (integrating additional ESD protection), but were given a less conservative bit rate specification. My guess is that this was due to the comfort level with higher-speed RS-232 operation increasing over time.

Max

I installed a MAX3238E in place of the TRSF. The lower slew rate on RXD (about 1us from -5 to +5) did indeed reduce the noise on the RTS input but I still see spikes of about +/- 1.2V on RTS, coinciding with rising/falling edges of RXD. This is uncomfortably close to the threshold voltage; even if it weren't its way more coupling than I'd ever expect to see in a system like this.

Donald,

How much of the coupling seems to occur within the cable and how much is within the PCB? If you see significant cross-talk without a cable connected, how close are the RXD/RTS PCB traces (and how long are they)? I'd be happy to review the layout if you could provide it.

In either case, is there a capacitance value that can be added to the "RIN" ports of the transceiver that resolves the issue? I'd expect this to be possible as long as the line-to-line capacitance (through which the edges are coupling) is not too large. If you can place a capacitance to ground on RIN that is greater than the line-to-line capacitance then it should create an impedance divider that attenuates any AC noise that is transferring.

Max

Without a cable attached we see a +/-500mV spike on RTS.  RXD and RTS are on adjacent pins on the 3238, and adjacent pins on the DB-25 connector (per RS-232 spec).  They run in parallel on the same layer, but only for about 1.5".  I will try to send you a copy of the artwork with the relevant nets highlighted - I'm not sure I have the right tools and permissions to pull that off.  I can't post complete artwork or schematics to a public forum

My board needs to work in multiple installations with varying cable lengths.  I'm not sure I'll be able to use a cap that's large enough to kill the noise without violating the specs of the devices on the other end of the cable.

Hi Donald,

I will look into running a similar test on this device next week just to see if there might be some cross-talk within the chip that we aren't aware of. Typically the parasitic capacitances in a chip are much smaller than on a PCB, but it's possible for cross-talk to occur through other means (e.g., via shared internal circuits, power rails, etc.). If that were happening here, I would expect similar noise levels across all the RIN inputs rather than higher levels on the lines adjacent to toggling signal lines - can you let me know if this is what you see?

Max