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: Andy Green
Subject: Re: [Discuss-gnuradio] USB2 <-> fast ADC & DAC
Date: Tue, 27 May 2003 21:14:48 +0100
User-agent: KMail/1.5

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 27 May 2003 20:01, Joseph DiVerdi wrote:

Hi Joseph -

> Based on the signal processing I expect to do to the data I could
> probably live with 10-bit resolution but must admit some reluctance
...
> rate is required not 23.4MSample/second ((10.7 + 1) * 2). The front
> end amplifier and track/hold devices must operate at the highest
> frequency but the ADC need not sample that high.
...
> BTW, some applications will require that the data be sampled by the
> ADCs at a specific time, that is, will require an external sampling

It seems that 2 differential ADC channels of 10...12 bit resolution 
are needed, capable of 21.4Msps, with differential input buffering.

An external differential clock input is needed (can this be done with 
a simple unipolar opamp as a saturating comparator with capacitively 
coupled inputs followed by a Schmitt trigger?).

I assume that a matching DAC with differential output buffering is 
also called for.

> Here is where there may be a significant gain available through
> undersampling. Please remember the Nyquist sampling requirement

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.

> One more system architecture thought: I have been involved in
> large-scale projects which were intended, at the outset, to be

I have a book about those kind of projects, entitled "Death March" :-)  
I take your point.

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.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+08c4jKeDCxMJCTIRAhv1AJsGygpkyYDCMiIAKogGRsrVrL8k4wCePsyY
sI+jseR5F6tLef8XKxBKuZ4=
=wWqF
-----END PGP SIGNATURE-----





reply via email to

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