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.

SN75C185: Issue with Duty Cycle

Part Number: SN75C185

I have a customer currently evaluating the SN75C185 for a RS-232 application.

They observed a difference in the length of time a single bit was HIGH or LOW, as shown in the attached image.

The waveform was measured at the output of the RS-232 driver IC.

- Baudrate = 115200bps
- The period is calculated as 8.7µs, and HIGH time is ~1.2µs too long, while LOW is ~1.2µs too short

From the DS, tPLH (L->H propagation delay) is 1.2µs typical, while tPHL (H->L propagation delay) is 2.5µs typical.
From this, it makes sense that the "HIGH" time would be longer than the "LOW" time...

But, from the standpoint of the RS-232-C standard, is this behavior (observed variation in H/L time length vs baudrate) acceptable?

  • Hi Darren,

    The standard itself is not too explicit on this point.  When defining signal rise/fall times it simply states:

    "Good engineering practice requires that the rise and fall times of the data and timing signals should be approximately equal (within a range of 2 or 3 : 1)."

    While this does not directly mention propagation delays, I believe the fundamental intention is to suggest that it is best not to have excessive distortion (without strictly defining what the acceptable threshold may be).

    Later it also mentions timing distortion more directly but only to say that high and low states should be held for nominally equal periods of time with some acceptable tolerances, although this seems to be specifically in reference to forwarded clock lines in synchronous systems rather than the asynchronous (UART) style communication typically used over RS-232 today.  It references TIA/EIA-334 for guidance on tolerances.

    Finally, there is a section on distortion which is just a single sentence:

    "The operation of the transmitting and receiving circuits should minimize the effects of any circuit time constants which would delay the circuit response time and introduce time distortion of the signals."

    So, there does not seem to be a clear limit for this defined in the RS-232 physical layer.

    One thing to keep in mind , though, is that the standard only covers operation up to 20 kbps.  So, this is usage is already outside of the bounds of just RS-232 (although such operation is very common).  I think the more relevant question is whether or not the bit timing distortion present on ROUT is likely to result in mis-sampling of the bit values by the host UART.  Typically there is enough timing margin between the sampling point and the edge transitions that this level of distortion can be tolerated, but it does depend on the UART design as well as the worst-case frequency variation between transmitting and receiving nodes as well as the length of the words transmitted (which would determine the maximum number of consecutive identical bit values and therefore the maximum distance between reference transitions that could be used for synchronization).

    One last thing to note is that many RS-232 receivers will place the high/low input switching threshold a little above 0 V.  In that case, some of this distortion would be recovered when the signals pass through the receiver (since the higher threshold effectively extends the "low" time).

    Max

  • Hi Max,

    I appreciate the really detailed feedback. It was very helpful.

    Just to summarize though, the RS-232-C standard doesn't have any specific value listed for frequency & bit distortion at up to 20kbit/s, right?

    Darren

  • Darren,

    That is correct.  There is no firm specification on this that I can find.  One thing I'll note is that the standard revision I reviewed is TIA-232-F, which supercedes all previous versions.  Generally I wouldn't expect for critical specifications like timing requirements to be removed in a standard revision, though.

    Max

  • Hi Max,

    Do you have any way of getting your hands on the RS-232-C revision somehow? I can't seem to find anything online...

    If you can manage to get official documentation on the RS-232-C standard from the 1960's (man this is an old standard...), could you just confirm that point? Or forward the material to me offline?

    Regards,

    Darren

  • Hi Max,

    I had a follow up question from the engineer about the SN75C185 connected to a MSP430, and if the MSP430 will be able to properly receive this data, with the different H/L lengths.

    Posted here: https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/932735

    Just to let you know...and if you had any comments on the subject, I would appreciate any advice you might have as well. (MSP430 in asynchronous samples the bit stream multiple times, taking the majority bit...the question is how this difference in H/L time affects that sampling process...)

    Regards,

    Darren

  • Darren,

    Thanks for the heads-up.  I just read through that thread and agree with where the discussion seems to be going at the moment.  I'll subscribe to it so I can chime in if needed.  I'll also keep looking for 232-C for further confirmation and can let you know offline what I find.

    Max