FreeCalypso > hg > fc-rfcal-tools
comparison doc/VCXO-vs-VCTCXO @ 64:65577bb967f7
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. |