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.

LMX2592: Calibrating Issue

Part Number: LMX2592
Other Parts Discussed in Thread: LMX2594, LMK61E2

We have been designing a downconverter using the LMX2592. Following the lineguide provided in the datasheet, we send the command "Calibrate" (writeR0[3]= 1) after every change in one of the frequency related registers: the command calibrate works fine. However, it happens quite often that a residual (symmetric) spur is present and, until a new calibrate command is sent, the spur is steady. We have tried disabling Autocal after the chip has done the calibration but nothing changed. In other words the spur appears and disappears following the calibrate command (writeR0[3]= 1). The frequency of the spur is ~5 kHz offset from the VCO and it is -60 dBc. The REF_IN is 156.250 MHz, the divider =2 thus the PFD is 78.125 MHz. The frequency of the spur is not related to the final VCO frequency as it still remains about at 5 kHz.

Thank you for support,

  • Hello Mario,

    Can you confirm / take a look at the following:

    • For 20 MHz < PFD < 100 MHz, R0[8:5] should be set to 4'b0000.
    • What are R1 and R4 set to?
    • What is your SPI clock rate, and how soon after changing the frequency are you writing R0[3] = 1 to calibrate the VCO?

    On a side note, what is your application and what frequency to what frequency are you converting from?

    Thanks,

    Vibhu

  • Hello Vibhu,

    thank you for your reply.

    1. Yes, REG 0 is set to 0x221C which means R0[8:5] set to 'b0000. By the way I do not understand the digit '4' you put after "set to".
    2. Registers are set to:
      1. R1 = 0x0808
      2. R4 = 0x1943
    3. SPI clock frequency is 4.1 MHz.
    4. As far as the delay of writing R0[3] I have tried many different values ranging from a few hundreds us up to seconds.
    5. The application is an upconversion (which is eventually followed by an additional downconversion). The input frequency is 20 MHz to 4 GHz which is converted fo 5.2 GHz.

    For you reference here are the fulI set of register (the frequency is set to 5430 MHz)

    R64    0x400077
    R63    0x3F00A8
    R62    0x3E0000
    R61    0x3D0001
    R59    0x3B0000
    R48    0x3003FD
    R47    0x2F08C0
    R46    0x2E1EA3
    R45    0x2DC600
    R44    0x2C053E
    R43    0x2B0000
    R42    0x2A0000
    R41    0x296500
    R40    0x281DCD
    R39    0x278204
    R38    0x260044
    R37    0x254000
    R36    0x240048
    R35    0x23119F
    R34    0x22C3EA
    R33    0x212A0A
    R32    0x20210A
    R31    0x1F0001
    R30    0x1E0034
    R29    0x1D0084
    R28    0x1C2924
    R25    0x190000
    R24    0x180509
    R23    0x178842
    R22    0x162300
    R20    0x14012C
    R19    0x130965
    R14    0x0E0AD4
    R13    0x0D4000
    R12    0x0C7002
    R11    0x0B0018
    R10    0x0A10D8
    R9    0x090302
    R8    0x081084
    R7    0x0728B2
    R4    0x041943
    R2    0x020500
    R1    0x010808
    R0    0x00221C

  • Hello,

    The "4" in "4'b0000" just to indicate 4 bits. Sorry if that confused you.

    Do you see the same issue when using a different input frequency?

    You can also try changing the state machine clock R1[2:0] and VCO calibration delay R4[15:8]. The register descriptions in the datasheet provide descriptions on what these bits do.

    Please also take a look at http://www.ti.com/lit/an/snaa336/snaa336.pdf

    Thanks,

    Vibhu

  • Hello Vibhu,

    thank you for your help. We have tried different settings according to your hints.

    As for the first question, do you mean different REF in freq or different PFD? We have tried a different PFD with no positive results. Changing the REF in Frequency is not strightforward beacause the oscillator is used by other parts.

    As for register changes, here is the report. Changing R4[15:8] does not produce any difference in the phenomenon. Instead, the R1[2:0] makes the behavior of spurs different. It is enough to change it from "b1000" to any other value to stop the "toggling" spur every time a calibrate command is issued. In other words, when  R1[2:0] is "b1000", as we have it now, for almost every calibrate command there is a toggle in spur (if there weren't any spur they appear while if spurs are present they disappear). Conversely, with R1[2:0] other than "b1000", for instance "b1001", the spur "status" remain unchanged after any calibrate command. So far, so good. However, this also means that if spurs were present they will be present forever and unfortunately this is what sometimes happens. In other words the improvement is quite big but it still remains the fact that if at start-up the two spurs appear they will last until the next switch-off.

    I hope my description has been clear enough to understand all I said. Of course do not hesitate to ask me any further elucidation you may need.

    Thanks a lot for your efforts in helping me.

    Best regards,

    Mario

  • Hello Mario,

    Thanks for the detailed response. I meant to test with different input frequency to see if there is a spur on the input at the same frequency as well that is being carried over, just for debugging purposes. If this is possible please try this, or perhaps measure the performance of the input to see any similarities. Based on your description however, I believe this is likely not the case.

    From what you say the R1[2:0] control makes the spurs behavior repeatable? ie You see the same spurs at the same places for different settings but this time re-calibration doesn't make them disappear. Were these spurs smaller than what you saw earlier?

    Also after you adjust R1[2:0] make sure you also adjust R4[15:8] if needed, as these settings are related, the information regarding this will be on the datasheet.

    Thanks,

    Vibhu

  • Hello Vibhu,

    thanks again for your support. As for changing the input frequency, it is not easy as the reference is the same for many other circuits, indispensable for checking spurs themselves, thus it would mean some HW work, ie cutting traces.

    Yes, by changing R1[2:0] I can make it repeatable: with R1[2:0] = "b000" spurs appear/disappear almost at every re-calibrating. Setting R1[2:0] = "b001" spurs, if present do not change or do not appear if not present. Spurs, when present, never change: neither frequency, nor amplitude.

    As far as R4[15:8], we have tried in many ways but it does not affect the behavior at all.

    I saw that the article you pointed out is related to LMX2594 rather than LMX2592. As we are considering passing to LMX2594, do you think that that device, perhaps, could not suffer this problem?

     Best regards,

    Mario

  • Hello Mario,

    It seems to me that the calibration was the issue, based on the behavior you described. Does the 5 kHz offset spur disappear in both cases (no spurs and permanent spurs)? If so that confirms that the issue was calibration realted.

    The article applied to both, or to be more accurate the LMX2592 has a similar calibration procedure as the document.

    Thanks,

    Vibhu

  • Hi Vibhu,

    no doubt it is related to calibration since my first post. In my view, it seems that something in the chip keep switched to a signal instead of being released. Sadly, I understand from your reply you have no hint anymore to come up with solution.

    Regards,

    Mario

  • Hello Mario,

    I took a bench measurement using the configuration you provided and actually, did not see any issues with calibration or any 5 kHz spurs. Keep in mind you can get better performance with a cleaner source. (I used the LMK61E2)

    Also I noticed that the configuration is for a 5340 MHz output and not a 5430 MHz output, can you confirm?

    If you are using TICSPro it might be worth a shot starting from the TICS Pro default and configuring the part as needed.

    Can you share what you see on your end?

    Thanks,

    Vibhu

  • Hi Vibhu,

    thanks again. I’ve never doubted you didn’t notice the phenomenon . As for 5340 MHz I confirm that I swapped ‘3’ and ‘4’: sorry by that.

    As you couldn’t reproduce it, It could be a peculiar problem related to our layout. As we have to make some other change I think it is better to wait for the next PCB and see it.

    Thanks again for your support,

    Mario