Hi,

For LPF bandwidth tuning, TXPLL generates 320MHz which is on chip divided by 8 to construct 40MHz reference frequency to tune RC product. Using any PLL frequency other than 320MHz will result in wrong tuning reference frequency i.e. wrong RC tuning code.

The question is why VCOCAP search fails while setting TXPLL to 320MHz. That should not happen.

Regards, Srdjan

On 08/10/2012 14:51, Gillian Seed wrote:
Hi,
I'm having a problem while trying to do a LPF Bandwidth tuning as described in a Programming and Calibration guide page 40, figure 4.5 and on https://github.com/chemeris/UHD-Fairwaves/blob/fairwaves/umtrx/host/utils/umtrx_lms.py#L433. Currently it seems to always fail when it's trying to find the VCOCAP value. I'm only getting Low printed before it fails. I was wondering why it takes a 320MHz frequency, because it's not described anywhere in the documents, could I try to do a bandwidth tuning with some other frequency as well? I'm running my code in a following order (http://lists.osmocom.org/pipermail/umtrx/2012-July/000075.html),

Example setup for ARFCN 925:

Initialization and auto-calibration:
  ./umtrx_lms.py --lms 1 --lms-init
  ./umtrx_lms.py --lms 1 --lms-tx-enable 1
  ./umtrx_lms.py --lms 1 --lms-rx-enable 1
  ./umtrx_lms.py --lms 1 --pll-ref-clock 26e6 --lpf-bandwidth-code
0x0f --lms-auto-calibration

RX LNA and RXVGA2 selection and gain control
  ./umtrx_lms.py --lms 1 --reg 0x75 --data 0xf0
  ./umtrx_lms.py --lms 1 --reg 0x65 --data 10

TX LPF control
  ./umtrx_lms.py --lms 1 --reg 0x34 --data 0x3e

LO leakage cancellation (calibration data values may vary)
  ./umtrx_lms.py --lms 1 --reg 0x42 --data 0x67
  ./umtrx_lms.py --lms 1 --reg 0x43 --data 0x89

TX/RX PLL charge pump current
  ./umtrx_lms.py --lms 1 --reg 0x16 --data 0x93

Tuning
  ./umtrx_lms.py --lms 1 --lms-rx-pll-tune 925.2e6
  ./umtrx_lms.py --lms 1 --lms-tx-pll-tune 880.2e6

TXVGA2 gain to max and enable PA
  ./umtrx_lms.py --lms 1 --reg 0x45 --data 0xc8
  ./umtrx_lms.py --lms 1 --lms-pa-on 2