Message	Date	From	Subject
1987	2008-08-25 17:40:42	Glen Leinweber	Codec undersampling question
Am looking at using audio type sigma-delta CODEC as a radio receiver I.F. analog-to-digital converter. And of course, am looking for short-cuts ;-) Most audio CODECs employ oversampled audio inputs. For example a Crystal CS5330 oversamples by 128, when the sample clock is 48 Khz. This sets the actual sampling rate at 6.144 Mhz. This particular chip has no internal analog low pass filter, so that a 6.168 Mhz. input signal should sample similarly to a 24 Khz. signal. The manufacturer expects the user to ensure no input signals exceed 24 Khz. Let us set our I.F. amplifier at 6.144 Mhz. and include a bandpass filter whose passband is fairly narrow, and whose stopband is well-attenuated and less than 48 KHz.. wide. Apply this signal directly to the CODECs audio input. This should result in digitized audio, with a 6.144 MHz input signal in the middle of our I.F. passband giving a DC (zero beat) output. The CODEC becomes both a product detector and analog-to-digital converter. A narrow passband with 6.144 Mhz. on one side becomes a SSB detector. I haven't tried this, but it should work in principle. It is quite likely that the CODECs sample/hold cannot handle such fast-changing signals without bad effects - this is pretty radical under sampling. Needless to say, the data sheets never characterize chip operation this way. Has anyone tried this - with what result? That is - how badly is audio performance degraded from normal operation?
1990	2008-08-27 13:29:47	Gary Johnson	Re: Codec undersampling question
Glen, The well-known concept you're considering is sub-Nyquist sampling; Google that topic, or "ADC undersampling", or look at places like dspguru.com or dsprelated.com for general info. It is an effective technique for reducing digital data rate, though you do have to concern yourself with some details. One, the analog bandwidth of the ADC needs to be sufficiently high and well-behaved in the parts of the spectrum of concern. Two, the aperture jitter (S/H and clock) has to be sufficiently low, consistent with the frequency of interest and the ADC resolution. Many high-speed ADCs are designed specifically for sub- Nyquist sampling of RF signals and are fully specified in those applications. You won't find such data with audio CODECs. That doesn't mean they won't work, but you really can't be sure unless you experiment. I think I'd stick with parts that are purpose-designed. Finally, there is some interesting math and a variety of tradeoffs regarding sampling rate and (analog) bandpass filter response. One excellent book that covers this is Richard Lyons "Understanding Digital Signal Processing." I'd recommend that book to anyone doing anything with DSP. 73, Gary, WB9JPS

Am looking at using audio type sigma-delta CODEC as
a radio receiver I.F. analog-to-digital converter. And of
course, am looking for short-cuts ;-)
Most audio CODECs employ oversampled audio
inputs. For example a Crystal CS5330 oversamples by
128, when the sample clock is 48 Khz. This sets the
actual sampling rate at 6.144 Mhz. This particular chip has
no internal analog low pass filter, so that a 6.168 Mhz. input
signal should sample similarly to a 24 Khz. signal. The
manufacturer expects the user to ensure no input signals
exceed 24 Khz.

Let us set our I.F. amplifier at 6.144 Mhz. and include a
bandpass filter whose passband is fairly narrow, and whose
stopband is well-attenuated and less than 48 KHz.. wide.
Apply this signal directly to the CODECs audio input.
This should result in digitized audio, with a 6.144 MHz input
signal in the middle of our I.F. passband giving a DC (zero
beat) output. The CODEC becomes both a product detector
and analog-to-digital converter. A narrow passband with
6.144 Mhz. on one side becomes a SSB detector.

I haven't tried this, but it should work in principle. It is
quite likely that the CODECs sample/hold cannot handle
such fast-changing signals without bad effects - this is pretty
radical under sampling. Needless to say, the data sheets
never characterize chip operation this way. Has anyone
tried this - with what result? That is - how badly is audio
performance degraded from normal operation?