LTC6948 ALCLO flag

ALC refers to Automatic Level Control.   It basically is optimizing the amplitude of the VCO for best phase noise.  It monitors the output of the VCO.  I typically set reg 3 = 0x3E, instead of 0x7E.  This turns off the ALCMON.  If you sent ALCEN=1 do the ALCLO/HI bits clear?  This may create some extra low level spurious response, but this just for debug...

What does the output look like on a spectrum analyzer?

Can you measure the DC voltages on pins  BVCO, TB, CMx, BB and TUNE?

I'd expect values around these numbers.

UNE: 1.6V to 2.9V(fixed)

CMx/TB: ~2.3V

BB: ~1.2V

BVCO: ~ 5V

Hi Chris - san,

Thank you for reply!

Please let me know if my understanding is correct.

> It monitors the output of the VCO.

The monitoring location of the ALC judgment block is unknown, but will it be monitored at the internal VCO output terminal?

Also, since the RF is output via an internal output buffer, won't the load circuit on the RF+/- pins affect the ALCLO/HI bit determination?

> I typically set reg 3 = 0x3E, instead of 0x7E.  This turns off the ALCMON.

Does this mean that reg 3 = 0x3E is the recommended setting value, and if reg 3 = 0x7E is set, it will not be determined as correct ALC control?

Is it possible to clarify the priorities of ALCCAL, ALCEN (prioritized to ALCCAL, ALCMON, and ALCULOK), ALCMON, and ALCULOK PLL, and the combinations that should not be set?

Is it possible to disclose information on ALCHI and ALCLO judgment blocks?

Below are the trouble situations that our customers are experiencing.

The RF output is outputting at the correct set frequency, and only the ALCLO error flag is generated on the STATE output.
Customer output frequency range: 2415.0M to 2468.0MHz The above phenomenon occurs around 2435 to 2445 MHz.

What are the possible concerns and causes?

Best regards,

sss

Hi Chris - san,

I have an additional question.

The THI and TLO flags can be understood to be useful for checking the CP status and debugging when PLL/VCO is unlocked.
On the other hand, I do not understand the situation in which the ALCHI and ALCLO flags are set even when ALC is active.
What kind of debugging should I do when these flags are set?

Best regards,

sss

The loading on the LTC6948 outputs should not affect ALC results as the ODIV output buffer/divider provides a constant load to the VCO output.  When the ACL circuitry is on, the ALC monitors the output amplitude of the VCO and then adjusts the bias to the VCO circuitry until the amplitude lands between a lower (ALCLO) and higher limit (ALCHI).  The levels for ALCLO and ALCHI are hidden to the user. 

Table 11 in the LTC6948 states that the ALCEN overrides ALCCAL, ALCULOK and ALCMON.  If ALCEN is set high it will have the highest priority.  This also implies the ALC circuitry is always on and will make changes to the VCO bias circuitry at anytime.  This can create some small spurious response in the output spectrum.  For spurious reasons I recommend setting ALCEN = L. If the customer is ok with small spurs that occur randomly, there is nothing wrong with setting ALCEN high.

 ALCULOK only occurs when the LTC6948 PLL when the LOCK bit is low (un-locked).  Ideally, the LTC6948 should only come unlocked during a frequency change or VCO calibration.  If unlock is occurring often, most likely there is a significant issue in the system.  It is unlikely that the unlock state is occurring due to a VCO amplitude change, but if it does, setting ALCULOK high will correct the amplitude.  I recommend setting ALCULOK high for this unlikely reason, it doesn't hurt anything.

ALCCAL is the most important bit in my opinion.  There is a bank of several different VCOs in the LTC6948 for different frequency bands.  Each VCO can use different bias conditions.  The VCO calibration process will select the correct VCO and the ALC will set the VCO bias that sets the correct amplitude during the VCO calibration process.  In theory a new VCO and bias setting are not required until a new frequency is programmed.  If ALCULOK is set high, it is not necessary to set ALCCAL as the LTC6948 is unlocked during calibration and therefore the ALC circuitry will be on. However, I still recommend setting the ALCCAL bit high also, it doesn't hurt.

For the situation you described above where most frequencies are not triggering the ACLLO error flag 

- is the customer performing a new VCO calibration with each frequency change?  If not, this may explain why the error is occurring.

- if the customer is performing a VCO calibration and receiving the ALC error flag, they can check the BDIV setting and ensure the VCO calibration is not too fast (described in datasheet).  Performing the VCO calibration with too small of BDIV setting, can cause the VCO calibration to pick the wrong VCO and as a result the ALC circuitry may not ever achieve a desired VCO amplitude.

- try a 2nd VCO calibration, maybe the first VCO calibration did not select the VCO.  I have never seen this happen with a proper device setup, so this would be strange if this was occurring.

Lastly, I requested some DC voltages measurements above.  CMx/BB/TB/VTUNE/B_VCO are all connected to the VCO internally.  If any of these voltages are not as expected, it can imply a setup issue - possibly wrong supply voltages, oscillating supplies, a poor reference, a register programming issue or some other issue.  Please check these voltages and let me know what they measure.

Hi Chris - san,

We received the following responses from our customers.

Their VCO and ALC register settings are below.
VCO calibration is set.
ALCEN:0 ALCMON:1 ALCCAL:1 ALCULOK:1 AUTOCAL:1 AUTORST:1 DITHEN:1 INTN:0
AUTOCAL:1 CAL: 0 MTCAL:1

The B_DIV settings are as follows.
BD[3]:0 BD[2]:1 BD[1]:1 BD[0]:0 = 0110 >>>6
B_DIV: 64 >>> 6
B ≥ fPFD / fCAL-MAX = 51.2MHz / 1.0MHz = 51.2 < 64
here
LTC6948-1: fCAL-MAX=1.0MHz
fPFD=51.2MHz (customer specifications)

The DC voltage measurement results for CMx/BB/TB/VTUNE/B_VCO are as follows.
This is the voltage measurement value when ALCLO occurs.
2441MHz 2438MHz 2435MHz
TUNE: 1.6V to 2.9V (fixed): 2.268V 2.251V 2.253V
CMx/TB: ~2.3V 　 2.305V Same as left Same as left
BB: ~1.2V 1.201V Same as left Same as left
BVCO: ~ 5V 4.996V Same as left Same as left
After the ALCLO flag occurs, if the customer sets the same frequency or another frequency again, the ALCLO flag will be cleared.
Customer output frequency: 2415.0M~2468.0MHz
This phenomenon occurs in the middle of the frequency band, around 2435MHz to 2441MHz.
2415MHz~(2435~2441MHz)~2468MHz
OK range ~ (NG range) ~OK range

Could you please give me some advice on finding the cause based on the above information?
If you have any additional confirmations for our customers, please let us know.

Best regards,

sss

Hi sss,

Based on the 3 Vtune voltages they provided they may be on the edge of VCO selection point during calibration.  This should not cause a problem, but I'm thinking that maybe slowing down the VCO calibration time to BD=0111, 0x7 may help.  The recalibration they are performing that changes the ALCHI/LO flag indicates that maybe slowing down the calibration could help also.

Can you confirm they are recalibrating the VCO for each frequency hop, initially?  It looks like they are based on the settings provided above.  

Are they seeing this on more than one unit? 

Can they check their settings against this GUI?  Are they using the same LDOEN, LDOV, CPCHI, CPCLO settings?

Chris

Chris

Hi Chris - san,

Attachments are customer settings.
The settings are the same except for the CP. (CP=11.2mA)

Does the customer need to change and confirm both B Count (64>>>96 )and CP(11.2>>>5.6mA)?

I have an additional question.
The data sheet has the following description.

The ALCHI and ALCLO flags, valid only when the ALC is active or the
ALCMON bit is set, may be used to monitor the resonator
amplitude.

Is it correct to understand that the ALCHI or ALCLO flags may be set even with the following settings when ALCMON is off?
ALCEN: 0, ALCMON: 0, ALCCAL: 1, ALCUOK: 1

Best regards,

sss

Hi sss,

Does the customer need to change and confirm both B Count (64>>>96 )and CP(11.2>>>5.6mA)?

Only change the B Count.  

Is it correct to understand that the ALCHI or ALCLO flags may be set even with the following settings when ALCMON is off?
Yes, the ALCHI/LO can be triggered when the ALC is active, with ALCMON off.  However, if the ALC is active it usually self clears these bits by adjusting the VCO amplitude, so one will rarely see the bits go high.  ALCMON is a way to monitor the VCO amplitude when the ALC circuitry is not active.

Hi Chris-san,

We received the following responses from our customers.

We changed only the B counter (BD[3:0]:6>>>7) and checked the ACLLO error flag, but the error flag remained there and did not improve.

Is it recommended that we change the B counter to 7 or higher (BD[3:0]:6>>>7~11) and check?
If we change the B counter above, will there be any problems with the IC operation?
Does it simply take longer to calibrate?

Are there any other considerations you recommend?

Best regards,

sss

Hi sss,

To be honest I am running out of idea's to check.  They can try to increase the BD counter further.  This will only cause a longer time to calibrate.  It will not affect anything else.  

I'm under the impression they are seeing this issue on a board they designed?  If so, I wonder if its time to see if they can desolder a unit and resolder it on an LTC6948 evaluation board and see if they see the same issue.  If not, we could send the unit back to QA.

Chris

Hi sss,

To be honest I am running out of idea's to check.  They can try to increase the BD counter further.  This will only cause a longer time to calibrate.  It will not affect anything else.  

I'm under the impression they are seeing this issue on a board they designed?  If so, I wonder if its time to see if they can desolder a unit and resolder it on an LTC6948 evaluation board and see if they see the same issue.  If not, we could send the unit back to QA.

Chris