• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 35 subscribers
  • Views 419 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.

Original question:

LMH0397: HD PLL Pathological Bit Error

LMH0397: HD PLL Pathological Bit Error

Conor
Guru 12065 points
Part Number: LMH0397
Other Parts Discussed in Thread: LMH0394, , LMH0324

Tool/software:

Hi,

The answer I got from the URL below is "When you set 0x28 = 0x22, there is no need to rewrite."
https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1386838/lmh0397-hd-pll-pathological-bit-error/5317733#5317733

However, from operational testing, we found that when the above settings are made in SD format, the cable compensation ability is significantly reduced. The cable compensation ability is reduced regardless of pathology or color bars. I think that the default value should be left as it is in SD format, but could you please comment again?

Thanks,

Conor

  • 0
    TI__Guru**** 176721 points

    Conor

    Due to the US Labor Day holiday, the response to your question may be delayed. We will look into your question when we return tomorrow, Sept 3rd. Sorry for the wait and any inconvenience it may cause.

    Thanks,

    David

  • 0 in reply to David (ASIC) Liu
    Guru 12065 points

    I understand that it is a US holiday. I look forward to hearing from you!

  • 0 in reply to Conor
    TI__Guru* 93670 points

    Hi Conor, 

    Register 0x28 is related to HD/3G only. However, this was not tested at SD rate to observe the side effect you are reporting. Do you know the data rate ahead of time ? I am thinking you can implement this workaround based on data rate. 

    Regards, Nasser

  • 0 in reply to Nasser Mohammadi
    Guru 12065 points

    Hi Nasser,

    As a result of the HD/3G countermeasures, there will be reception problems with SD, so it is highly likely that the registers will have to be rewritten for each band. Would you be able to provide any verification or comments regarding this? Also, is the LOCKRATE setting value what you would like to know?

    Thanks,

    Conor

  • 0 in reply to Conor
    TI__Guru* 93670 points

    Hi Conor,

    You can check data rate and then decide whether to implement this or not. 

    Regards, Nasser

  • 0 in reply to Nasser Mohammadi
    Guru 12065 points

    Hi Nasser,

    Nasser Mohammadi said:
    Do you know the data rate ahead of time ? I am thinking you can implement this workaround based on data rate. 

    The data rate is 270Mbps (SD-SDI). I would like to know why the cable compensation ability drops significantly when 0x28 = 0x22 is set in SD format. Also, I think that register 0x28 should be left at the initial value (0x00) in SD format, but what is your opinion? For SD-SDI, there is no problem if Register 0x28 is set to 0x00.

    When connecting a 5CFB 200M cable with HD-SDI, an error occurs when the cable is shaken. It becomes very stable when the reclocker is removed. I would also like to confirm whether there is a (hidden) register to adjust the reclocker parameters.

    Thanks,

    Conor

  • 0 in reply to Conor
    TI__Guru* 93670 points

    Hi Conor,

    Sure you can leave reg 0x28 at default setting of 0x00 for SD data rates.

    It is possible perhaps when you shake the cable there is connectivity issue or your BNC connector may not be making a good contact. Shaking the cable should not change the cable parameter but maybe with this 5CFB cable somehow it gets affected. There is no a CDR parameter can compensate for this.

    Regards, Nasser

  • 0 in reply to Nasser Mohammadi
    Guru 12065 points

    Hi Nasser,

    To summarize the contents of this thread.

    --
    For HD SDI, setting 0x28 = 0x22 solves the problem, but inputting SD SDI does not work properly. When changing the register, behavior for SD SDI input has not been verified.
    --

    If the above is correct, I would like your comments on the following.

    When the CDR is in bypass state and an HD SDI pathological pattern is input, no error occurs. This means that no error occurs if the CDR loop response frequency is set to infinity.

    In other words, the cause of the error is presumably the finite loop response characteristic of the CDR.

    If the loop bandwidth can be expanded, wouldn't that be a solution? Please tell me how to expand the loop bandwidth. Also, please tell me whether it will affect SD SDI.

    Thanks,

    Conor

  • +1 in reply to Conor
    TI__Guru* 93670 points

    Hi Conor,

    By expanding loop bw, you are passing all the jitter to the device attached at the output of the device(LMH0397) - for example FPGA or ASIC receiving signal from LMH device. In this case, you can just bypass CDR as you noted. Or you can also consider a part without CDR - such as LMH0324 or LMH0394. If you want to change SD loop bw, please send me a friend request and i can look into this.

    Regards, Nasser 

  • 0 in reply to Nasser Mohammadi
    Guru 12065 points

    I have sent you a private message, please reply and I will close this thread.