• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 900 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.

TRS3223E: TRS3223EIPWR RS232 TXD Jitter

Steve Chiang
Prodigy 10 points
Part Number: TRS3223E

你好，我是Askey的RD，我們使用TRS3223EIPWR將UART信號轉換為RS232信號，在附上的波形中我們測量RS232 TXD信號，發現會有400ns左右的jitter，請幫忙確認400ns的jitter是否在可容忍範圍內，如果您能提供建議的抖動範圍值或文檔，我們將不勝感激。

  • 0
    Prodigy 10 points

    Hello, We use TRS3223EIPWR to convert the UART signal to RS232 signal, in the attached waveform we measure the RS232 TXD signal, and find that there will be a jitter of about 400ns, please help to confirm the jitter of 400ns Is it within the tolerable range, and if you can provide a suggested jitter range value or document we would be very grateful.

  • 0 in reply to Steve Chiang
    TI__Mastermind 48108 points

    Hi Steve,

    We do not include a jitter spec in our datasheets but we do include a pulse skew specification for the driver which is typically 100ns. This number can change with a multitude of factors: pulse skew of driver, bus capacitance, signal rate, and cable length are just a few ideas to think about when designing a system with low jitter.

    I have provided two applications notes that talk about jitter. These were mostly written for RS-485 specific applications, but the general knowledge is applicable to RS-232 applications. 

    https://www.ti.com/lit/an/slyt179/slyt179.pdf?ts=1645805358180&ref_url=https%253A%252F%252Fwww.google.com%252F

    https://www.ti.com/lit/an/slla375/slla375.pdf

    Is there a certain jitter range you are trying to obtain for your application? What cable length are you using for RS-232 communication? 

    Regards,

    Tyler

  • 0 in reply to Tyler Townsend
    Prodigy 10 points

    Hi Tyler,

    The RS232_TXD we output from TRS3223EIPWR does not have any capacitors, and directly connects a 3m long cable through the connecto on the PCB.

    We want to confirm whether the quality of our signal and the jitter we have measured are acceptable?

    In addition, when we measure the waveform, the back end is not connected to any equipment, the waveform is purely the signal after the TRS3223EIPWR passes through the cable.

    Best Regards

  • 0 in reply to Steve Chiang
    TI__Mastermind 48108 points

    Hi Steve,

    Steve Chiang said:
    We want to confirm whether the quality of our signal and the jitter we have measured are acceptable?

    I don't believe that a jitter specification exists for RS-232 applications. 

    Steve Chiang said:
    In addition, when we measure the waveform, the back end is not connected to any equipment, the waveform is purely the signal after the TRS3223EIPWR passes through the cable.

    Also, since you are obtaining scope captures after 3m of cabling, any delay or jitter is a factor of the transceiver + cable, not just the transceiver itself. Cabling may add extra capacitance / length of cable, adding to over all delay and jitter. 

    I am thinking out loud here, but if you go off of your scope capture, I can estimate that your data rate is 115200bps? If that is the case, 1/115200 = ~8.68us is the length of one bit. You show around ~400ns max of jitter. For a frame of data with 1 start bit, 8 data bits, 1 parity, and 1 stop, we can total about 10 bits that need to be accurately sampled (not including stop bit). If the sample point is in the middle of the bit (50%), we can estimate that the receiving device will sample at ~4.34us. If you take total number of bits (10) * 400ns = 4.0us of deviation that could potentially result at parity bit, before the stop bit. 4.0us + 4.34us = 8.34us.

    (8.34us / 8.68us) * 100% = 96.083%

    This means that at the parity bit, your sample point could potentially deviate from 50% (in the middle) to 96.083% (towards the very end) of the parity bit. This could potentially cause a framing error since you are sampling so close to the end of the bit. You might also miss sampling the stop bit, and result a framing error on the 11th bit. Therefore, it might be necessary to have data frame that includes 2 stop bits instead of the normal 1. 

    Some sources suggest that at 115200bps, your max cable length should be <2.5m. However, there are many factors that would go into this assumption. 

    Regards,

    Tyler

  • 0
    Prodigy 10 points

    Hi Tyer,

    Could you provide the maximum and minimum UI size required for rs232 at 115200 bps?

    thanks,

  • 0 in reply to Steve Chiang
    TI__Mastermind 48108 points

    Hi Steve,

    Could you quickly elaborate on what you mean by "minimum UI size required for RS232 at 115200bps?"

    Regards,

    Tyler

  • 0
    Prodigy 10 points

    Hi Tyler,

    "minimum UI size required for RS232 at 115200 bps?" refers to the minimum amount of UI that can be accepted when IT is subtracted from one unit of time.

    Regards,

  • 0 in reply to Steve Chiang
    TI__Mastermind 48108 points

    Hi Steve,

    We currently do not provide jitter timing data on the datasheet for the TRS3223E as jitter is not a specification listed in the RS-232 standard. The best timing specifications that we can provide is driver max data rate, pulse skew, and slew rate. Receiver prop delay low-to-high and high-to-low, enable/disable timing, and pulse skew. 

    I have contacted validation/test engineering about how we test jitter in our RS-232 devices.

    Regards,

    Tyler