• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 33 subscribers
  • Views 599 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

LOR Holdover

Brian Fair
Prodigy 250 points
Other Parts Discussed in Thread: LMH1983, LMH1981

I have the LMH1981 chip connected to the LMH1983 chip and PLL4 is connected to an FPGA configured for 24.576MHz output.  The LMH1983 is in default mode, which should put the chip in Genlock mode and with LOR the part should go into holdover mode.  When I connect a blackburst source, everything works great.  When I disconnect the blackburst source the LMH1983 does not seem to go into holdover mode.  It seems like the control voltage to the oscillator is at .4V so it is obviously not holding over the 1.68V I read when the blackburst source is connected.  Any ideas?

My only thought is to change the default behavior to go freerun with LOR and setup the voltage control to 1.65V but that really isn't holdover.


Thanks.

  • 0
    TI__Guru* 88915 points
    Hi Brian,

    1). Do you have SMBUS access and can you read register 0x01 bit 4? This tells you if the device has gone into the hold over mode.

    2). Also, if you put your scope on PLL4 when you remove the reference do you see a jump on PLL4?

    Regards,,nasser
  • 0 in reply to Nasser Mohammadi
    Prodigy 250 points

    1. I wrote code to access the registers and register 1 bit 4 is reading it is in holdover mode when I pull out the blackburst cable and when I plug in the blackburst cable, it is reading it is not in holdover mode.  This is the expected behavior.

    2. I put a scope on PLL4 output and I see some jitter when plugging and unplugging the blackburst but it doesn't go away and it isn't enough to reset my FPGA PLL.  

    I tried setting register 5 bit 2 to a 1 for freerun mode.  That seemed to work just as expected.  Again any ideas for why holdover mode is not working?  Can I talk to you to discuss this as we need to solve this quickly.

    Thanks 

  • 0 in reply to Brian Fair
    Prodigy 250 points
    One more piece of information. When the blackburst clock is plugged in, registers 0x16 and 0x17 seem correct. When the blackburst is unplugged, registers 0x16 and 0x17 do not seem correct which is where the error is occurring. I'm not sure what is causing this.
  • 0 in reply to Brian Fair
    TI__Guru* 88915 points
    Hi Brian,

    Please send me an email at nasser.mohammadi@ti.com and i will call you.

    Regards,,nasser
  • 0 in reply to Nasser Mohammadi
    Prodigy 150 points

    Hi Nasser,

    is it possible that you could post the information on this board?

    I had also noticed that the 1983Evaluation board http://www.ti.com/lit/ug/snlu001/snlu001.pdf on page 8 shows a button labelled as 'Holdover workaround'. Is there a known problem when using this holdover mode that requires a workaround?

    regards

    John

  • 0 in reply to JohnW
    TI__Guru* 88915 points
    Greetings John,

    When the input and output video frames are aligned and afterward the LMH1983 reference input is removed, the LMH1983 is expected to keep running at the same frequency as before(for example hold over mode).

    There are cases where after removing the reference signal there could be spurious hsync pulses - resulting in VCXO control voltage to change. This could continue until we have reliable hsync pulses. The LMH1981 could exhibit this behavior when removing the reference signal.

    To prevent intermittent or false hsync pulses to trigger LMH1983 to change VCXO control voltage, the following workaround could be used:
    1). Once we detect No_Ref or loss of lock(whichever is faster) we should force hold over mode to prevent the VCXO control to drop drastically due to intermittent hsync pulses.
    2). De-bounce No_Ref to make sure we don’t get fooled by false or short No_Ref pulses.
    3). Once we determine No_Ref is indeed de-asserted we enable genlock.

    Regards,,nasser