The present disclosure pertains to oscillator frequency control and, more particularly, to methods and apparatus to control frequency offsets in digitally controlled crystal oscillators.
As will be readily appreciated, crystal oscillators or crystals, which are found in many electrical circuits, are devices that are fabricated to resonate at predefined frequencies in response to applied voltages. For example, the ubiquitous color burst crystal resonates at a frequency of 3.57954 megahertz (MHz) and may be found in almost every television and radio manufactured.
Many systems and circuits utilize crystal oscillators to provide a clock reference representative of relative time. For example, microprocessors and microcontrollers typically utilize crystal oscillators to derive system clocks that control the rate at which data is read by input/output ports and/or the rate at which programming instructions are executed.
Communication systems and components such as telecommunications infrastructure and mobile units use crystal oscillators to generate one or more frequencies that are useful in producing radio frequency (RF) signals onto which information to be broadcast and received is imparted. For example, a crystal oscillator is usually used to generate a master reference clock that is used to synchronize information exchange between telecommunications infrastructure and mobile units.
Crystal oscillators all have tolerance ranges associated with their resonant frequency. The difference between the ideal resonant frequency of a crystal oscillator and the actual operating frequency of the crystal oscillator is referred to as the frequency offset of the crystal oscillator. For example, a crystal oscillator may be specified to have a tolerance between 10 parts-per-million (PPM) and 100 PPM at an operating temperature of 25° C. However, it is a rare situation in which a crystal oscillator is operated at the specified 25° C. temperature. Accordingly, in practice, the actual operational frequency of a crystal oscillator may vary outside the specified 25° C. tolerance. Therefore, there is almost always a frequency offset in a crystal oscillator.
Some applications, such as communications systems, require a high degree of crystal oscillator precision (i.e., very low frequency offset) to prevent interference with neighboring communication channels. To control more precisely the resonant frequency of a crystal oscillator, some communication systems utilize a digitally controlled crystal oscillator (DCXO) system in conjunction with a crystal. A DCXO system typically includes a processing portion that monitors the resonant frequency produced by a crystal oscillator and alters the resonant frequency of the crystal oscillator by outputting a code to a DCXO circuit that changes the capacitive loading on the crystal oscillator to tune the frequency of the crystal oscillator. The capacitive loading is typically achieved via one or more programmable capacitors having digital interfaces that accept the DCXO codes and change capacitance in response to the DCXO codes.
In practice, when a DCXO system is first powered up, such as when a mobile telephone is turned on, an initial DCXO code is used to set the loading capacitance of the crystal oscillator. The initial frequency output by the crystal needs only to be within a few PPM of the target frequency (i.e., a relatively large offset). After communication is established with another entity, fine frequency tuning may be carried out during which the DCXO changes its output code to refine the load capacitance and bring the resonant frequency within fractions of a PPM of the target frequency (i.e., to lower the offset).
Based on various environmental characteristics, such as process, voltage, and temperature (PVT) variations, the resonant frequency of a crystal oscillator may not meet the initial frequency accuracy of a few PPM under all conditions (i.e., the initial offset of the frequency system may be larger than desired). Therefore, many manufacturers calibrate a DCXO with an initial code for operation with a particular crystal oscillator at one specific temperature (e.g., 25° C.) and store the DCXO code associated with that crystal in memory, such as flash memory, before shipping the product. In the field, when the device attempts to establish initial communication, the DCXO code stored in memory is applied as a first attempt to load the crystal oscillator to achieve the desired oscillator frequency.
However, even when the pre-calibrated DCXO code is loaded, there is no guarantee that the ambient temperature of the crystal oscillator is the same as the calibration temperature at which the initial DCXO code was selected. Additionally, there is no guarantee that the temperature coefficient of the crystal, the supply voltage, and the DXCO circuit will not shift the frequency offset produced using the DCXO code to an unacceptable level. Further, as crystals age, their resonant frequencies may change, thereby potentially rendering the initial DCXO code ineffective.
In an attempt to improve the initial offset of the crystal oscillator caused by temperature, some manufacturers provide a temperature sensor associated with the DCXO and a fixed lookup table within a memory. The fixed lookup table stores a number of DCXO codes, each of which corresponds to a different sensed temperature. On system startup, the DCXO reads the temperature from the temperature sensor, retrieves from the fixed lookup table the DCXO code corresponding to the sensed temperature, and applies the retrieved DCXO code to initially calibrate the crystal oscillator. However, this solution does not account for crystal aging effects, temperature coefficient changes, or crystal replacement.
As shown in
The infrastructure 104 may be implemented using a base transceiver station (BTS) that is configured for wireless communications with the mobile unit 102. The infrastructure 104 may be coupled to one or more other infrastructure units, the plain old telephone system (POTS), or any other suitable network. As with the mobile unit 102, the infrastructure 104 may be implemented as a GSM base station, or as any other FDMA, TDMA, or CDMA compatible base station. In the example of
As described below, the mobile unit 102 may initially calibrate its crystal oscillator using a DCXO system on power up. After initial crystal oscillator calibration, the mobile unit 102 establishes communications with the infrastructure 104 through the use of handshake messages 112. The handshake messages 112 may include the mobile unit 102 informing the infrastructure 104 of its presence in the area serviced by the infrastructure 104, or any other suitable communications required to make the mobile unit 102 and the infrastructure 104 compatible and ready to exchange voice and data over RF channels.
As part of the handshake messages 112 provided by the infrastructure 104, the infrastructure 104 provides a frequency control message to the mobile unit 102. For example, if the mobile unit 102 and the infrastructure 104 operate using the GSM protocol, the infrastructure provides the mobile unit 102 with a frequency control burst (FCB) on a frequency control channel (FCCH). In a known manner, the mobile unit 102 receives the FCB and calculates its frequency error. The DCXO system adjusts its DCXO code to tune the oscillator frequency accordingly.
After the handshake messages 112 complete, and the mobile unit 102 and the infrastructure 104 are configured to exchange information, audio messages 114 may be exchanged. As will be readily appreciated by those having ordinary skill in the art, in digital communication systems, the audio messages are exchanged as sequences of encoded symbols representing bits and bytes of information that are used to reconstruct the analog audio to be exchanged. Additionally, although reference has been made to audio messages, those having ordinary skill in the art will readily recognize that data messages, video messages, and/or any other types of messages maybe exchanged in the system 100 of
Turning now to
As shown in
In more detail, the DCXO controller 202 may be implemented by any combination of hardware, firmware, and/or software. For example, the DCXO controller 202 may be implemented in hardware as an application specific integrated circuit (ASIC), either as a stand-alone device or as a portion of a larger device including a significant number of systems and circuits. Alternatively, the DCXO controller 202 may be implemented as software or firmware code executed by a microcontroller or a microprocessor. For example, the DCXO controller 202 may be a generic microprocessor or microcontroller, and software and/or firmware may be stored in the memory 206 and loaded by the microcontroller or microprocessor at power up or some other time to implement the functionality of the DCXO controller 202. Of course, in such an arrangement, the microcontroller or microprocessor may be used to implement other functions or perform other activities in addition to those performed by the DCXO controller 202. More specific examples of the DCXO controller 202 as implemented in software/firmware code and as hardware functional blocks are described in conjunction with
The transceiver 204, which may include a receiver portion that receives RF signals from an antenna 214, may be implemented using hardware, software, firmware, or any suitable combination thereof The transceiver 204, regardless of its specific configuration, receives and processes RF signals provided by infrastructure (e.g., the infrastructure 104 of
The transceiver 204 may also be coupled to other circuits and components 218, which may include transmit and/or receive circuitry, audio circuitry such as an earpiece speaker and/or a microphone. For example, a microphone may be coupled to the transceiver 204 so that a user's voice may be converted into electrical signals and transmitted. Similarly, the transceiver 204 may provide received audio to an earpiece speaker so that a user may hear audio.
The memory 206 may be implemented using any suitable memory device or technology. For example, the memory 206 may be implemented using non-volatile memory such as flash memory. Alternatively, the memory 206 may be composed of any number of different memory technologies. The memory 206 may be an individual device or may be integrated with the DCXO controller 202. Further, the memory 206 may be exclusively dedicated to DCXO functionality or may be shared with other systems and circuits.
As shown in
The temperature sensor 208 may be implemented by any suitable temperature sensing device configured to sense the temperature of the oscillator 212, or at least the ambient temperature thereof. For example, the temperature sensor 208 could be implemented using a positive temperature coefficient (PTC) or negative temperature coefficient (NTC) thermistor, an infrared sensor, or any other suitable device. The temperature sensor 208 may be located proximate the oscillator 212 so that the temperature of the oscillator 212 may be provided to the DCXO controller 202.
As will be readily appreciated, the indication of the temperature to the DCXO controller 202 may be provided in an analog or a digital format. For example, the temperature sensor 208 may output an analog voltage corresponding to the sensed temperature. Alternatively, the temperature sensor 208 may include circuitry that produces digital bits or bytes representative of the sensed temperature. In either case, the DCXO controller 202 receives the temperature indication and processes the same. For example, the DCXO controller 202 may include an on-board analog-to-digital converter that samples analog temperature signals from the temperature sensor 208, or may include a bus or register for receiving a digital temperature indication.
The DCXO circuit 210 responds to the DCXO codes output from the DCXO controller 202 to alter the resonant frequency of the oscillator 212. Further detail of one example implementation of a DCXO circuit 210 is shown in
The example DCXO circuit 210 also includes an output buffer 308 from which the output frequency (Fout) is taken. The output frequency may be connected to various other systems and circuits. The frequency of the signal from the output buffer 308 is substantially identical to the resonant frequency of the oscillator 212. However, the output buffer 308 prevents any other circuits from substantially affecting the resonant frequency of the oscillator 212 by providing isolation (e.g., a high impedance load) to the oscillator 212.
While the DCXO circuit 210 of
The oscillator 212 may be implemented using any suitable oscillator. For example, the oscillator 212 may be a crystal oscillator, a ceramic resonator, or any other type of device that resonates at a particular frequency when a voltage is applied thereto. The oscillator 212 should be capable of being loaded to change its resonant frequency so that the DCXO circuit 210 can vary a reactive load in the resonant circuit to affect the operating frequency of the oscillator 212. The oscillator 212 may have a resonant frequency in any suitable range, such as, for example, 1 MHz to 300 MHz.
A process that may be performed by the DCXO controller 202 is shown in
The illustrated DCXO process 400 begins operation by reading a temperature sensor (e.g., the temperature sensor 208 of
To this point, a DCXO code has been selected from the memory 206 based on temperature and used to minimize the offset of the oscillator 212. Once the DCXO code is output, the device in which the oscillator is located (e.g., the mobile unit 102) establishes communications with infrastructure (e.g., the infrastructure 104). As part of establishing communication with the infrastructure, the infrastructure will, in a known manner, provide the DXCO controller 202 with a frequency indication, such as a FCB, which is described above. Based on the FCB, the DXCO controller 202 will, in a known manner, adjust the DCXO code to lock the frequency of the mobile unit with the frequency of the infrastructure (block 408). For example, the DCXO controller 202 will vary the reactive load in the DCXO circuit 210 to move the resonating frequency of the oscillator 212 to the frequency dictated by the frequency indication (e.g., the FCB).
To take advantage of the adjusted DCXO code used to synchronize the oscillator frequency with the infrastructure frequency, the process 400 reads the temperature sensor (block 410) to determine the latest temperature of the oscillator (i.e., the temperature most closely corresponding to the adjusted DCXO code). Subsequently, the process 400 stores the adjusted DCXO code in association with the sensed temperature (block 412). For example, the adjusted DCXO code and the sensed temperature may be stored in the lookup table 220 residing in the memory 206. After the adjusted DCXO code is stored, the process 400 ends or returns control to its calling routine.
Storing the adjusted DCXO code in association with the temperature to which the code corresponds enables the DCXO controller 202 to more accurately attempt initial calibration of the oscillator 212 at a subsequent point in time. For example, over time the DCXO code for 25° C. may increase due to aging, but this increase will be reflected in the lookup table 220. Accordingly, in the initial calibration procedure described above in conjunction with blocks 402-406, the DCXO code read from the lookup table 220 for 25° C. will be the adjusted DCXO code. Therefore, the initial calibration of the oscillator 212 (i.e., the calibration that takes place before infrastructure communication is established) is more accurate and has a lower frequency offset.
Of course, modifications to the process 400 may be made. For example, depending on the time between the initial temperature sensor reading and the storage of the adjusted DCXO code in the memory 206, a second temperature sensor reading (block 410) may be omitted. In particular, if there is little time and/or little reason for the temperature of the oscillator 212 to change during the period of time between the initial temperature reading and the time at which the adjusted DCXO code is generated, there would typically be no need to read the temperature a second time.
An example implementation of a DCXO controller 202 is shown in
After communication is established with another entity (e.g., with infrastructure 104), the DCXO controller 202 receives a frequency indication, such as an FCB. A DCXO code adjuster 508 then determines an adjusted DCXO code that is output to the DCXO to adjust the oscillator frequency. Subsequently, the DXCO code adjuster 508 provides the adjusted DCXO code to the memory interface 506 so that the adjusted DCXO code may be stored in memory 206. The memory interface 506 may also read the sensor interface 504 to determine the current oscillator temperature, which will be stored in association with the adjusted DCXO code.
Although certain methods and apparatus constructed in accordance with the teachings of the invention have been described herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers every apparatus, method and article of manufacture fairly falling within the scope of the appended claims either literally or under the doctrine of equivalents.
This application incorporates by reference and claims the benefit of U.S. Provisional Application No. 60/517,119, filed Nov. 3, 2003.
Number | Date | Country | |
---|---|---|---|
60517119 | Nov 2003 | US |