FreeCalypso > hg > fc-rfcal-tools

comparison doc/VCXO-vs-VCTCXO @ 64:65577bb967f7

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/VCXO-vs-VCTCXO written
author Mychaela Falconia <falcon@freecalypso.org>
date Sun, 28 May 2017 05:02:24 +0000
parents
children
comparison
equal deleted inserted replaced
63:131abadbd74d 64:65577bb967f7
1 Some TI-based GSM mobile station devices use VCTCXOs (voltage-controlled,
2 temperature-compensated crystal oscillators), while others use "plain" VCXOs
3 without the TC part. The Leonardo reference design for the Calypso+Iota+Rita
4 chipset, adopted first by Openmoko and then by FreeCalypso, uses a "plain" VCXO,
5 and the Rita RF chip itself was designed with non-TC VCXOs in mind, as it
6 includes the active part of the XO on-chip, with the external VCXO circuit
7 becoming purely passive. The same Rita chip does support the option of
8 disabling its internal active XO part and using an external VCTCXO; this
9 approach is used in the Pirelli DP-L10 GSM+WiFi dual mode phone - but it is no
10 longer Leonardo, and not properly supported by our available TCS211 reference
11 firmware.
12
13 However, it appears that Rita was TI's first RF chip to include the on-chip
14 active part for a non-TC VCXO, whereas Clara (D-Sample) and earlier RF chips
15 always required the VCXO or the VCTCXO to be external. Furthermore, it appears
16 that TI's original approach in the days of Sara RF (before Clara) was to use
17 VCTCXOs mandatorily, then later they improved their AFC (automatic frequency
18 control) algorithm to work with the cheaper non-TC VCXOs, and eventually the
19 non-TC VCXO approach became standard.
20
21 It also appears that the requirements for VC(TC)XO calibration changed with the
22 transition from VCTCXOs to "plain" VCXOs: of the two TI calibration documents
23 we have (see TI-docs), the Sara document seems to assume a VCTCXO, whereas
24 LoCosto's DCXO is apparently more like the Leonardo VCXO.
25
26 TI's Layer 1 sources we have include a C preprocessor symbol called VCXO_ALGO,
27 defined to 1 in TCS211, and it is my (Mychaela's) guess that this preprocessor
28 symbol enables the new code developed for non-TC VCXOs. The dac_center,
29 dac_min and dac_max fields in the afcparams table (T_AFC_PARAMS) exist only
30 when VCXO_ALGO is nonzero, and these numbers are calibrated per unit on Openmoko
31 devices. Without VCXO_ALGO the afcparams table contains only Psi constants,
32 and it is my guess that in the days of Sara VCTCXOs these Psi constants were
33 calculated theoretically and hard-coded, rather than calibrated per unit, hence
34 the lack of corresponding calibration instructions in the Sara
35 rf_calibration.pdf document. Only the "EEPROM" DAC value set with rfpw 10
36 needed to be calibrated back then, apparently.
37
38 It is not particularly clear to me whether or not the non-TC VCXO used with
39 VCXO_ALGO really needs to be calibrated on a per-unit basis, or if it would be
40 sufficient to calibrate it on a per-design basis and put these per-design
41 calibrated values in the firmware image. My own experience indicates that the
42 frequency put out by the non-TC VCXO varies quite significantly with
43 temperature, thus even if the factory calibration is done in a temperature-
44 controlled chamber, it is not clear how much this calibration helps in
45 subsequent end user operation when the phone can be used in a very cold
46 environment or a very hot one, and must work flawlessly nonetheless.
47
48 The truth may very well be that TI supplied their chipset customers with their
49 standard production calibration software that includes the VCXO calibration
50 step before Rx and Tx calibrations, and it was easier for the device
51 manufacturers to just run this production calibration software as-is than to
52 understand the meaning of various numbers in the afcparams table and come up
53 with some good-for-all values. TCS211 firmware does not work without VCXO
54 calibration on Openmoko's modem or on our semi-clone thereof (FCDEV3B) because
55 the hard-coded values of the Psi constants (which Openmoko couldn't change
56 because they were shackled by binary-only libs) are too far from the correct
57 values for the VCXO featured in this design, but the calibrated Psi values
58 differ very little from one unit to the next.
59
60 We no longer have the binary-only problem that Openmoko faced, but our current
61 approach is to replicate Om's factory per-unit calibration procedures pretty
62 closely, including the VCXO calibration.