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.

LMX2572EVM: Inconsistent Self Calibration with Automatic Ramp

Part Number: LMX2572EVM
Other Parts Discussed in Thread: LMX2491

Tool/software:

I am currently working with the LMX2572EVM in order to test out an application that utilizes the automatic ramp feature.  I have been successful in using the CalibrateVCO feature when performed with the automatic ramp turned off and the PLL set to the center of my ramp frequency range and then enabling the ramp.  The problem is that I am sometimes getting a "bad calibration" with the CalibrateVCO feature that causes the PLL to go out of lock when the ramp is enabled.  This is evident by looking at the spectrum on a spectrum analyzer that shows very high sidebands outside of the intended ramp frequency range.  I would like to understand why I sometimes get a "bad calibration" and how to avoid it in my application. I usually get the "good calibration" but get the "bad calibration" about 10% of the time.

My center frequency will range from 2410 to 2490MHz with an automatic ramp that is 20MHz wide.  I have attached my register values for a "good calibration" as well as a "bad calibration" when set to a center frequency of 2442MHz.  My procedure is to turn off the ramp, set the PLL to 2442MHz, click on the CalibrateVCO button, set the PLL to the beginning of the ramp or 2432MHz and then enable the 20MHz automatic ramp.  90% of the time, the output spectrum looks good with most of the energy spanning from 2432 to 2452MHz as desired.  However, about 10% of the time, the spectrum has very high sidebands outside of the desired frequency range.  In the attached example register files, the "good calibration" R110 is "0178" while it is "0D78" for the "bad calibration".  Should Vtune indicate locked during an automatic ramp?  There is also a slight difference in R111 which is "010B" for the "good calibration" and "010F" for the "bad calibration" but I don't know if this is enough to cause the bad calibration or why I get a different value sometimes.  These are the only differences in the register values between a "good calibration" and a "bad calibration" that I can find.  Thanks!

R125	0x7D2288
R124	0x7C0000
R123	0x7B0000
R122	0x7A0000
R121	0x790000
R120	0x780000
R119	0x770000
R118	0x760000
R117	0x750000
R116	0x740000
R115	0x730000
R114	0x727802
R113	0x710000
R112	0x70EE5F
R111	0x6F010B
R110	0x6E0178
R109	0x6D8D7D
R108	0x6C00A1
R107	0x6B8801
R106	0x6A0007
R105	0x690000
R104	0x682710
R103	0x67FD61
R102	0x663FFF
R101	0x650010
R100	0x642710
R99	0x63029F
R98	0x620000
R97	0x610000
R96	0x600000
R95	0x5F0000
R94	0x5E0000
R93	0x5D0000
R92	0x5C0000
R91	0x5B0000
R90	0x5A0000
R89	0x590000
R88	0x580000
R87	0x570000
R86	0x568F5D
R85	0x55FDC2
R84	0x540001
R83	0x538F5D
R82	0x5203C2
R81	0x510000
R80	0x500000
R79	0x4F0080
R78	0x4E0001
R77	0x4D0000
R76	0x4C000C
R75	0x4B0800
R74	0x4A0000
R73	0x49003F
R72	0x480001
R71	0x470081
R70	0x46C350
R69	0x450000
R68	0x4403E8
R67	0x430000
R66	0x4201F4
R65	0x410000
R64	0x401388
R63	0x3F0000
R62	0x3E00AF
R61	0x3D00A8
R60	0x3C0000
R59	0x3B0001
R58	0x3A9001
R57	0x390020
R56	0x380000
R55	0x370000
R54	0x360000
R53	0x350000
R52	0x340421
R51	0x330080
R50	0x320080
R49	0x314180
R48	0x3003E0
R47	0x2F0300
R46	0x2E07F0
R45	0x2DC600
R44	0x2C3FA3
R43	0x2BA3D7
R42	0x2A3D70
R41	0x290000
R40	0x280000
R39	0x27FFFF
R38	0x26FFFF
R37	0x250205
R36	0x240030
R35	0x230004
R34	0x220010
R33	0x211E01
R32	0x2005BF
R31	0x1FC3E6
R30	0x1E18A6
R29	0x1D0000
R28	0x1C0488
R27	0x1B0002
R26	0x1A0808
R25	0x190624
R24	0x18071A
R23	0x17007C
R22	0x160001
R21	0x150409
R20	0x144848
R19	0x1327B7
R18	0x120064
R17	0x110096
R16	0x100080
R15	0x0F060E
R14	0x0E1808
R13	0x0D4000
R12	0x0C5001
R11	0x0BB018
R10	0x0A10F8
R9	0x090004
R8	0x082000
R7	0x0740B2
R6	0x06C802
R5	0x0530C8
R4	0x040A43
R3	0x030782
R2	0x020500
R1	0x010808
R0	0x00A118
R125	0x7D2288
R124	0x7C0000
R123	0x7B0000
R122	0x7A0000
R121	0x790000
R120	0x780000
R119	0x770000
R118	0x760000
R117	0x750000
R116	0x740000
R115	0x730000
R114	0x727802
R113	0x710000
R112	0x70EE5F
R111	0x6F010F
R110	0x6E0D78
R109	0x6D8D7D
R108	0x6C00A1
R107	0x6B8801
R106	0x6A0007
R105	0x690000
R104	0x682710
R103	0x67FD61
R102	0x663FFF
R101	0x650010
R100	0x642710
R99	0x63029F
R98	0x620000
R97	0x610000
R96	0x600000
R95	0x5F0000
R94	0x5E0000
R93	0x5D0000
R92	0x5C0000
R91	0x5B0000
R90	0x5A0000
R89	0x590000
R88	0x580000
R87	0x570000
R86	0x568F5D
R85	0x55FDC2
R84	0x540001
R83	0x538F5D
R82	0x5203C2
R81	0x510000
R80	0x500000
R79	0x4F0080
R78	0x4E0001
R77	0x4D0000
R76	0x4C000C
R75	0x4B0800
R74	0x4A0000
R73	0x49003F
R72	0x480001
R71	0x470081
R70	0x46C350
R69	0x450000
R68	0x4403E8
R67	0x430000
R66	0x4201F4
R65	0x410000
R64	0x401388
R63	0x3F0000
R62	0x3E00AF
R61	0x3D00A8
R60	0x3C0000
R59	0x3B0001
R58	0x3A9001
R57	0x390020
R56	0x380000
R55	0x370000
R54	0x360000
R53	0x350000
R52	0x340421
R51	0x330080
R50	0x320080
R49	0x314180
R48	0x3003E0
R47	0x2F0300
R46	0x2E07F0
R45	0x2DC600
R44	0x2C3FA3
R43	0x2BA3D7
R42	0x2A3D70
R41	0x290000
R40	0x280000
R39	0x27FFFF
R38	0x26FFFF
R37	0x250205
R36	0x240030
R35	0x230004
R34	0x220010
R33	0x211E01
R32	0x2005BF
R31	0x1FC3E6
R30	0x1E18A6
R29	0x1D0000
R28	0x1C0488
R27	0x1B0002
R26	0x1A0808
R25	0x190624
R24	0x18071A
R23	0x17007C
R22	0x160001
R21	0x150409
R20	0x144848
R19	0x1327B7
R18	0x120064
R17	0x110096
R16	0x100080
R15	0x0F060E
R14	0x0E1808
R13	0x0D4000
R12	0x0C5001
R11	0x0BB018
R10	0x0A10F8
R9	0x090004
R8	0x082000
R7	0x0740B2
R6	0x06C802
R5	0x0530C8
R4	0x040A43
R3	0x030782
R2	0x020500
R1	0x010808
R0	0x00A118

  • Hi Ed,

    We will take a look in next week.

  • Hi Noel,

    I’ve spent more time investigating this problem and I now believe that calibration differences that I observed were not related to the problem.  I have now forced the calibration values to be fixed for a given frequency so that they cannot change but I still see the problem.  I have been able to get the “bad modulation” to be “good modulation” just be unchecking and then checking the “RAMP_EN” button several times.  When the modulation is "bad", the VCO control voltage ramps from a high value of about 1.9V down to about 0.9V but then drops suddenly to a constant value of about 0.7V for the lower voltage (higher frequency) ~10% of the triangle wave before popping back up to 0.9V to continue the ramp. However, I can uncheck and then check the "RAMP_EN" button and then the VCO control voltage changes to a perfect triangle wave ramping between 1.9V and 0.9V. 

    I have also noticed that the Vtune lock indicates unlocked almost all of the time, even when the modulation is “good”. 

    Here is my current list of questions:

    1. Is there a corrective action to prevent the “bad modulation” problem described above?
    2. Should the Vtune lock indicator function when ramping?
    3. How do you recommend that I determine if I have enough design margin to utilize a calibration free ramp?  I know that I can change the calibration parameters by a few values or change the center frequency by a few MHz and still have acceptable modulation. My temperature range is relatively small (~50C) and I’ve not observed significant changes in calibration parameters over this narrow temperature range.
  • Hi Ed,

    First of all, during ramp, VCO frequency is changing, so the lock detector will try to keep tracking the lock status. As a result, rb_LD_VTUNE or the MUXOUT pin is not trustable, we cannot use this indicator to determine lock.

    I have some questions to your good register settings.

    Is the reference clock 100MHz?

    After loading this register settings to TICS Pro, I got below PLL configuration, is it correct?

    on the ramp page, I see below. RAMP0 is 4824Mhz to 6000MHz. This does not seem right to me.

    If you use TICS Pro, could you send your .tcs file to me?

  • The reference clock is 100MHz but the RAMP0 is incorrect.  Here is an example .tcs file:

    2468MHz with 20MHz Ramp.tcs

  • Hi Ed,

    Ramp range is 40MHz but ramp threshold is 50MHz, so this is a calibration-free automatic ramp. 49xxMHz is in the middle of VCO4, I believe calibration free should work. I will try to extend the ramp limit to something like 8GHz (HIGH) and 2GHz (LOW). 

    I have another question, charge pump gain is 625µA, I expect the loop bandwidth is going to be small. This may affect the ramp performance. Is there a reason for small loop bandwidth?

  • That is good news that you feel that the calibration-free automatic ramp should work in this application.

    The charge pump gain was set low only to reduce phase noise but I could increase this to improve ramp performance if you think that it would help since phase noise is not critical in this application.

    Unfortunately, I will need a reliable lock detector when ramping for this application.  I've been looking around for alternative solutions and found the LMX2491.  It seems to me that I will have more flexibility by using an external VCO with a higher VCO gain so that the control voltage can be kept well away from the lock detect limits.  The LMX2491 also seems to have more flexibility in setting the charge pump voltage monitor limits so that I can make sure that I don't get false lock detect alarms when ramping.  Does this make sense to you?

  • Hi Ed,

    I tried your configuration, it works.

    However, you can see there is some distortion at the beginning of each ramp, this is due the lower loop bandwidth with only 625µA charge pump current.

    if I make the charge pump  current to 2.5mA, distortion gets improved.

    I also tried LMX2491, LD stays HIGH during ramping. This devices support 8 different ramp profiles, allows you to make more complicated ramp waveform.

  • Thanks Noel for checking on this.  We will go with the LMX2491 for the desired function of the LD line.  

    Best Regards,

    Ed