• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 20 subscribers
  • Views 387 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.

Original question:

LMX2595: Loss of reference detection

LMX2694-EP: MUXOUT still functions as Lock detect? for OscIn loss after calibration (during operation)

John Wielgus
Prodigy 10 points
Part Number: LMX2694-EP

Hello, 

A question to clarify the function of MUXOUT when set as Lock detect, during steady state operation.

Specifically, how does the Lock detect (MUXOUT) act if Ref Osc input is lost during steady state operation?

Meaning, after a successful cal and programming for frequency, what does MUXOUT (set as Lock detect) output if the Ref Osc input is lost? (meaning lost after cal)

Datasheet 7.3.6. sections imply LO Lock indicates successful cal and programming at time of initial programming, but does not accurately reflect, nor update, the LO Lock state during operation following a cal. (?)

Is this actually an operating LOCK detect? or... only indication of successful programming at time of Cal (i.e., at time of frequency set.)

Follow on: I presume the LMX2694 (or other integrated VCO synths) lose lock if the Ref OSCIN is lost? How is loss of lock indicated if the Lock detect is not updated?

Trying to clarify some datasheet confusion.

thank you for your help,

J. Wielgus

  • 0
    TI__Mastermind 28960 points

    Hi John,

    The MUXOUT lock detect function is determined by the LD_TYPE field, either VCOCal (whenever the VCO is calibrating, lock detect goes low, otherwise high), or Vtune and VCOCal (logical OR with a circuit that detects if Vtune voltage is at one of the rails). However, both of these functions require the internal state machine clock to be running, to latch the results of one or the other detector into the MUXOUT buffer. The state machine clock is always derived from the OSCin input. So if OSCin suddenly goes away (for example, if you connect OSCin to a signal generator and disable the signal), the state machine will suddenly halt, and the lock detection output latch will not be able to update. On the other hand, if the OSCin connection is intermittent (for example, if you physically remove the cable connecting the OSCin signal), or if the OSCin pins catch a few stray clock edges after OSCin is removed, this can be enough to advance a state machine cycle and latch the updated lock detect signal.

    In other words, if there is no signal on OSCin, the MUXOUT lock detect indicator state is frozen, and should not be considered valid. It could freeze low (OSCin removed while the VCO was calibrating, or while the PLL was unlocked if using Vtune+VCOCal lock detect), or it could freeze high (PLL was locked using Vtune+VCOCal, or was not calibrating if just using VCOCal).

    However, the rb_LD_VTUNE field monitors the Vtune voltage rail detector instead of the MUXOUT latch. If you read back the value of this field, you should be able to determine if the PLL is locked, regardless of whether OSCin is present. To prove this, I did the following:

    • Locked the PLL, configured MUXOUT for lock detect. State of MUXOUT is 1.
    • Removed OSCin cleanly. State of MUXOUT is still 1, but PLL is unlocked.
    • Changed MUXOUT to SPI readback, and read back the value of rb_LD_VTUNE as unlocked.
    • Re-applied OSCin, and read back the value of rb_LD_VTUNE as locked.
    • Removed OSCin cleanly, and read back the value of rb_LD_VTUNE as unlocked.
    • Changed MUXOUT to lock detect. State of MUXOUT is still 1, but PLL is unlocked.

    Regards,