discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] USB2 <-> fast ADC & DAC


From: Joseph DiVerdi
Subject: Re: [Discuss-gnuradio] USB2 <-> fast ADC & DAC
Date: Tue, 27 May 2003 17:18:44 -0600

Dear Andy,

<snip>
>Fascinating stuff...is this going to require filtering in software 
>though?  Next year we can expect entry level PCs to be operating at 
>3GHz (or 150 CPU clocks per sample at 2 x 10Msps) but the less work 
>that needs doing the better, since although the code and local data 
>can run in CPU cache the incoming data will mostly not be.
<snip>

It is pretty much a given that filtering/band shaping is required *prior* to 
and *following* digitization but for different signal processing reasons.

Hardware filtering is always required prior to digitization to prevent 
undesired signals and/or noise from being captured by the ADC(s). This 
anti-alias filtering is necessary to limit the signals presented to the ADC to 
the intended frequency range. Without such filtering (either through actual 
filtering circuitry or through band shaping of the various analog stages 
preceding the ADCs) the digital data stream is contaminated with either noise 
and/or spurious signals.

Software filtering is often required following digitization to select one or 
more desired signals from the captured data. 

In my own application a relatively wide swath of the VLF radio spectrum 
(roughly 5-100kHz) is collected by the ADC (and band limited by the amplifier 
stages preceding the ADC). After digitization, multiple "channels" (each 
several hundred Hz wide) are collected simultaneously and in parallel by 
software filtering prior to software demodulation. The number of channels which 
can be collected is limited only by the power of the CPU and associated 
hardware which implement the filters and demodulators.

<snip>
>I meant though more that the device is intended to perform as a very 
>local subsystem, it offers its published capabilities and has no 
>dependencies outside of them, eg, it is USB bus powered, specifies 
>exactly what kind of input it wants, what kind of throughput it can 
>handle, etc.  Generic in the sense it is an independent component.  
>Once what it has to do is defined (thanks to your input that is quite 
>advanced and is compatible with its original use too) it just has to 
>live up to that, not also cure cancer :-)  It would be perfect if it 
>became a kind of jellybean that people have lying around for any 
>random jobs that fit its capability.
<snip>

Sounds very OK to me. However, you did leave out "scramble eggs" and "flush 
toilets". ;)

Best regards,
Joseph
-- 
Joseph A. DiVerdi, Ph.D., M.B.A.          
http://xtrsystems.com/           970.980.5868 (voice) 
PGP Key ID: 0xD50A9E33




reply via email to

[Prev in Thread] Current Thread [Next in Thread]