
www.Usenet.com
| <-- __Chronological__ --> | <-- __Thread__ --> |
"Jan Panteltje" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On a sunny day (Tue, 18 Nov 2003 12:35:19 +1300) it happened Jim Granville > <[EMAIL PROTECTED]> wrote in <[EMAIL PROTECTED]>: > > > You could also try a Tracking ADC, rather than SAR - SAR is sensitive > >to > >noise, and have 'noise gain' which means large OP impulse errors can > >come from small IP errors. (which is what you are seeing) > > Tracking ADCs are better behaved, and would suit the faster speed / > >but not analog-optimised resource in the FPGA. > > > > - jg > Interesting, how (in priciple0 would you realize a 'tracking ADC'? > I left out the trigger (conversion request) and reset. > I start with the r2r DA at 128 (half of 255 8 bit range), > and the substractor at 64 (half of remaining range. > One clock later I check the comparator output, and store > the bit. > If the value was bigger I go to 128 + 64 and compare again.. > if smaller to 128 - 64... This is SAR, as you mentioned. Tracking ADCs have a saturating Up/Dn counter, and INC/DEC based on the comparitor result. They have a finite slew rate, but the counting clock speed can be higher than the read-out rate. Their advantage is the inherent low pass/noise filtering nature of the feedback so in a 'less than ideal' environment like a FPGA Comparitor/DAC, they could help. They can be made adaptive, so the INC/DEC size increases if many INC/DECs occur in the same direction (as in ADPCM), to improve the step response. -jg
| <-- __Chronological__ --> | <-- __Thread__ --> |