Feeds:
Posts
Comments

Archive for May, 2008

An Analog-to-Digital Converter (ADC) does exactly what the name implies: it converts an analog electrical signal to a digital representation. Specifically, the analog signal is a continuous-time continuous-amplitude signal, and the digital signal representation produced by the typical ADC is a sequence of discrete-time discrete-amplitude samples. The process of conversion from a high-resolution signal to a low-resolution signal is also known as quantization.

The two main types of ADCs are oversampling converters and Nyquist-rate converters, and there are several architectures for these. In most cases, there is some form of uniform quantization being performed on a high-resolution signal, in order to represent it in terms of a finite set of quantization levels. The error that results from quantization is referred to as quantization error. The spectral representation of random quantization error is known as quantization noise.

An ADC requires a clock signal to synchronize the instances when the analog signal is sampled. The clock frequency is referred to as the sampling rate, i.e. the rate at which samples are taken, and can be denoted fs. It is important that the clock have little or no clock jitter, which creates uncertainty in the sampling instant, and hence increases the quantization error.

An ADC also typically requires a reference voltage, denoted by VREF, which determines the valid voltage range over which the analog input signal can be converted. The input range of an ADC that only operates on positive voltages would go from zero volts, or circuit ground, to VREF. If the analog signal takes on values outside this voltage range, a well-designed input circuit will non-catastrophically limit the ADC to either minimum or maximum voltage, depending on the input signal. As expected, this would produce either a minimum or maximum digital value at the output.

The most common representation used for the digital samples produced by an ADC is a string of binary digits (or bits), where 00..0 represents the smallest analog input, and 11..1 represents the largest. These are sometimes referred to as ADC output codes. An N-bit binary number can represent at most 2N unique levels, and therefore, an N-bit ADC can produce 2N unique codes.

The quantization step or width of each ADC code can be denoted q, where q = VREF/2N. The nominal ADC code width is expected to be equal to a single LSB (least-significant bit), which is the right-most bit in a binary word representation. When the code width is normalized to VREF, q = 1/2N.

In the figure above, an example of a 3-bit ADC encoder transfer function is shown on the left, relating the digital output to the analog input. The encoder transfer function is arranged so that any input signal less than q/2 produces the smallest digital code, 000, input signals between q/2 and 3q/2 produce the next digital code 001, and so on. Alternate arrangements are possible, depending on the specific application requirements of the ADC.

The quantization error resulting from using this encoder transfer function is shown in the figure above on the right, and in this case, it takes values over the interval [-q/2,+q/2]. This assumes that the ADC input is appropriately limited and the digital output code is saturated when the input signal goes outside the operating range of the ADC.

The figure below shows the result when a full-scale sine wave is provided at the input to an ADC with this encoder transfer function.

It should be apparent that quantization is a highly non-linear process, and this makes it very difficult to perform an exact analysis of an otherwise linear system. In order to use classical linear analysis, it is necessary to derive a suitable linearized model of the quantizer, and this will be covered in a future post.

Copyright © 2008 – 2012 Waqas Akram. All Rights Reserved.

Advertisements

Read Full Post »

Ever since the Apple Mac operating system switched to its Unix-based underpinnings with Mac OS X, one of the most useful tools for Mac users has been the Fink Project. Their stated aims to “bring the full world of Unix open source software to Darwin and Mac OS X” has been wildly successful for those of us still reliant on Unix tools despite having guiltily moved on to one of the major commercial operating systems.

Some of the software tools available through Fink include Gnu/Emacs (which I had admittedly already installed on my powerbook from source), the Xfig drawing program, and the teTeX distribution of the TeX document preparation system invented by Donald Knuth. The totality of these three tools comprise all that I need in order to write and publish papers in my preferred format of TeX.

The Fink Project homepage has a link to a binary installer for the PowerPC version of Mac OS (as well as the newer Intel architecture). Once Fink has been installed, the shell paths need to be updated to use the specific fink directory paths. The Fink Project decided to use entirely separate Unix System Resources (/usr/) and binary (/bin/) locations as the main Unix installation by Mac OS. These are located in the seemingly arbitrarily named directory of /sw/. I agree with this setup decision because it minimizes the potential for interference between the Mac system Unix installation and the Fink project installation, especially during future updates.

Based on the Debian package management system (apt-get, etc), fink keeps a list of package dependencies in order to maintain all software within its purview. This tree of dependencies is used to ensure that all software libraries are installed or updated before any dependent updates take place. In this way, your open source software always remains in full working order without the problems that accompany out-of-date libraries.

Not all packages are available in binary format, and need to be built from source. This can be done by first installing the Apple Xcode developer tools (available from http://developer.apple.com/), which includes versions of the Gnu Compiler Collection (gcc). Finally, many older graphics-oriented tools such as xv and tgif require the X window system, or X11. Although X11 is available through Fink, there is also a version available directly from Apple. Fink allows either to be in use by its applications, and this can easily be configured.

Read Full Post »