| ??? 10/21/07 22:13 Read: times |
#145979 - Can't use average-too slow Responding to: ???'s previous message |
Christoph Franck said:
You can start with 8 or 16. Or, heck, even just 2. Nothing stops you from varying the number of samples you average. You can start with just two and have a maximum of, say, 16 in your window. And the "multiple sample" requirement doesn't change with the type of filter you use. You will need to average/filter several samples in order to stop the last bit from flickering. Actually, if it's only the last bit that flickers, 4 samples should be enough to stop it from doing that, since you get an additional bit of precision for every 4:1 averaging step (so, 1 bit for 4:1, 2 bits for 16:1 and so on). I have already said that I am using a dual slope integrating a/d converter, each sample takes around 400mSec approx., it's actually a sub multiple of 50Hz in order to reject the 50Hz line frequency. In otherwords, I'm obtaining about 2 samples per second, taking 4 or 16 or 32 samples is simply too long. As I have explained, if you are using flash or sar adc's then taking 50 samples and then dividing the end result by 50 does stabilise the last two digits, but doing this kill's the performance of such fast adc's not to mention the added processing time, and sar type adc's are limited to a maximum of 13 bits(linearity issues) whilst flash usually 8 bits due to price. In any case, all the top manufactures are using multi slope(fast) adc's(derivative of dual slope) due to high resolution/accuracy. Christoph Franck said:
Digital signal processing is, at first, a sub-discipline of mathematics and has exactly nothing to do with the processor you use. Except hardware and compiler price, not to mention single cycle 64bit floating point+MAC's, barrel shifters and about 250 flops at your disposal? Christoph Franck said:
Well, you were asking for how to get a stable signal, and not for a math lecture. I never made any reference to Laplace/Z inverse transforms nor DSP nor FIR's?, only the basic first order differential equation which governs the well known CR circuit, as a realistic starting point. Christoph Franck said:
I don't know if I could give the complete derivation from the top of my mind (start with the first-order differential equation, sidetrack into Laplace transformation, derive Z-transformation from Laplace transformation, arrive at a discrete time representation of the first-order differential equation). There are lots of different numerical methods to solving first/second order differential equations besides Laplace such as: Euler-Cauchy Runge-Kutta etc, etc But hell, come on... I am not asking to solve the CR equation, just to take a look at it and try and figure out how to convert it to an algorithm. The question is, how do I implement a simple CR circuit in software in order to stabilise the last digit? By the way, the reason the last digit(s) does flutter is because every adc, irrespective of type or form, is because they are differentiators as far as signal is concerned. Cheers for now Jason |
