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/u….
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