LMX2595: Loss of reference detection
Part Number: LMX2694-EP
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,
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:
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.