Quote:
Originally Posted by amb /img/forum/go_quote.gif
No doubt -- for an electronic display. For an analog meter, a lot of the attack performance will be in the meter mechanism itself. No electronics, cpu or not, is going to force a needle to move faster than it could.
|
not even if we dedicate a whole b22 board as a meter/needle driver?
then, the needle will get there even before the command to get there finishes!
Quote:
I contend, though, using a CPU and firmware just for a meter display is overkill in a certain sense. |
I like the ability to place ANY curve you want on there, with no pain and with fast turn-around to see the results. even hot-swappable (user selectable) ranges.
you could do trick stuff like, if the signal goes below a certain range, you can go into 'expanded scale' mode. nite time listening, as one use-case.
do I want to see average, peak, rms or just a bunch of needle movement to show the channel is active? all selectable if you go the software route.
Quote:
Nevertheless, if you want the display to be accurate at 20KHz then you need to A/D the signal at >40KHz. Assuming we want 60dB of dynamic range, you can see that there is quite a bit of data to be sampled and processed. I haven't done the math, but I have a gut feeling that a little CPU like the Arduino would be insufficient. |
I was *never* thinking of sampling *that* much. enough to drive a meter, which would be a fraction of the audio freq. maybe a few hundred samples per second, if even that. I'm not doing DSP, man; I'm just trying to get some needle movement trackage
how fast DO you have to change the needle's position in order to make a good VU meter? I'm not sure we can easily define what an ideal VU meter is, anyway; its a meter, afterall, and if you wanted a peak-hold led display you would have asked for that (the OP would have).
so front-ending a physical meter movement with an arduino class cpu sounds entirely reasonable to me. you get some sampled audio that is smoothed with a cap and read that via the a/d port as fast as you can, then for each reading you apply the mapping (linear or non-linear; probably via some lookup table to make it run faster) and then you come up with a resultant output voltage that gets sent out via another analog pin on the cpu, to the meter movement. and the cpu would do all the 'fades' that are needed (so if the signal suddenly dropped out, the user might want the meter to slowly sink down instead of dropping suddenly. or not - but it would be up to the user to specify).
the ard. can sample an IR receiver module, for example, and 'follow' its waves (38khz carrier, usually) and be able to find where the transitions are and count bits to decode the raw IR protocol. if the ard can follow an IR stream at this bit level, I bet it can keep up with enough analog sampling and also some transform mapping to a new output voltage, in enough time to keep onlooking humans amused enough