ruffrecords said:
Let me play devil's advocate for a moment.
Won't take my word for it...? The guy who told me is dead now (RIP) so we can't ask him.
For an 8 LED meter you still need 8 LEDs for both solutions
yes, there is an overhead associated with using a microprocessor (like unique 3.3V PS rail). For an 8 LED meter I doubt it makes much sense. How many consoles have you seen with only an 8 LED meter?
and also an op amp based peak detector.
um NO.... The rectification, peak and average attack and release time constants can all be performed inside the digital domain. In fact tricks like peak hold for any time length is easier in digital.
A couple of quad comparators are dirt cheap and don't take up much more room than a cheap PIC or cost any more.
They do involve more placements (assembly cost is based on machine touches). The PCB area reduction for a small 8 LED meter is not effective.
The PIC does not need a resistor ladder but you need a current limit resistor for each LED.
Not if you use a modern LED latch driver (like TLC59025) . One resistor can set the current/brightness for all 16 LEDs. That said my friends console meter used HCT logic SR latches and one resistor per LED, the modern LED drivers were not widely available yet.
Once built, the comparator one just works. Before it is built you need to spend some time = money programming the PIC. With the comparator version you don'y have to worry about EMC. WIth the PIC you do because you have an oscillator. I would have thought the cost and size differences were minimal.
Cheers
Ian
Once programmed, the microprocessor version just works. You just copy and print the code into each meter board before you use it. If we were doing higher volume production we could have saved some time and had the code burned into the micros before building the meter boards but we preferred the flexibility of being able to burn the latest software teaks into production boards.
The software is a one time NRE offset by reduced BOM and assembly cost for every unit sold. Since i didn't charge for the software design, I actually reduced their manufacturing cost. The really irritating thing is that microchip reps gave them all the free swag, and didn't care that I existed.... Probably didn't want to visit MS. :
This project was not done to save manufacturing cost. That was just an unintended benefit. I did the software design effort for free because I wanted to see my patented meter out in the wild, and I worried about my friends analog consoles competing in an increasingly digital world. (I fear my meter was too little digital too late).
There is noise from analog LED meters too as I am sure you know Ian. Using a latch line per LED can keep that noise component similar in a digital approach to what comes from analog meters.
The micro I used for my friends console design uses an internal free running clock, so there was no system clock existing anywhere outside the micro package. The only external digital switched lines were data and SPI to clock data into the HCT shift registers to light the LEDs.
The noise from the SPI communication was not audible and barely measurable without a spectrum analyser, but visible down in the dirt of the measurement floor, so we knew it was there.
I don't recall the final disposition but think I ended up increasing the frequency of the SPI network to reduce the visible hash in the noise floor.
That console meter used 5V HCT shift registers for the LED latches so needed per LED resistors and an additional 5V supply. Using a modern LED latch driver would reduce the SPI communications down to 3.3V and probably draw less current in the com /data lines. Driving the 5V logic from a 3.3V processor involved some open drain with pull up monkey business that probably increased digital noise too.
I am not advocating adding anything digital inside a premium old school analog chassis, but it did not degrade the audio performance of this well respected high performance analog design.
My cost saving comparison was vs. a simple one characteristic (peak or ave) meter... My digital meter delivered simultaneous peak and VU, as well as handling some console functionality (solo meters, etc). The cost difference to deliver the same peak and VU functionality with analog would be even greater (I know I've done that too).
JR