PIC LED VU meter

GroupDIY Audio Forum

Help Support GroupDIY Audio Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
I'm finishing off a design for a pre-manufactured module that is all SMD, teeny, tiny, with a small 10 LED array, with programmable thresholds.

https://www.facebook.com/photo.php?v=484126688397632&l=3002706066466014736

Should be live in about a month or so.

/Dafydd
 
Nice..

I am not loving the ballistic but I have been messing with LED meters for several decades so have my personal preferences.

That looks like a fast peak with a little faster release than I would use. Not to lobby you to change your design but my old peak/VU patent is long expired so that approach is public domain and free to use.

I like to see a similar fast attack peak characteristic to light a single floating LED but with a slower peak release (say 200 mSec). Then overlay a solid bar display of slow attack/slow release average signal (I use 200msec/200msec).  By  making the release time of the peak and ave display the same, the spread between peak and ave display remains constant after signal stops and the display decays.

I also prefer to make the LED spacing log (I used 3 dB steps). This way the peak to average spacing remains consistent over the entire meter range.

I experimented with calculating a true RMS value for the average display but did not see any difference on complex music, so returned to simple average math for the bar display.

Sorry about the hijack... One feature we included in the commercial version of my meter used in a console master section was a user selector switch so the customer could select Peak only, VU only, or Peak & VU simultaneously. While all the customer feedback I heard loved the Peak & VU.

Have fun... people always love lots of blinky lights.

JR
 
Hello,

I'm working on a project to add input/output/GR on my THAT compressor.
I have seen many discussions about it, and some are advocating a microcontroller, and others are voting for analog.

I found a post from John Roberts, describing his circuit with a microcontroller and a SPI bus.
In addition, Mackie uses analog for its Onix console. cf attached file.

What is the best in your opinion  ?
Thanks

Pascal
 

Attachments

  • Meter PCB.pdf
    366.3 KB · Views: 30
The Onyx circuit is the classic comparator circuit that  all small format mixer manufacturers use. YOu could do worse than copy it.

Cheers

Ian
 
In decades of console design I have designed many meters using many technologies.  That Mackie approach is pretty common for old school analog.

I've told this story several times but when I designed a PIC based meter for a friends console company he remarked that the digital approach was cheaper (and smaller) than their previous analog meter.

JR
 
JohnRoberts said:
I've told this story several times but when I designed a PIC based meter for a friends console company he remarked that the digital approach was cheaper (and smaller) than their previous analog meter.

JR

Let me play devil's advocate for a moment. For an 8 LED meter you still need 8 LEDs for both solutions and also an op amp based peak detector. A  couple of quad comparators are dirt cheap and don't take up much more room than a cheap PIC or cost any more. The PIC does not need a resistor ladder but you need a current limit resistor for each LED. 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
 
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
 
JohnRoberts said:
Won't take my word for it...? The guy who told me is dead now (RIP) so we can't ask him. yes,
[/quote
Not knowing what you friends original design was means there may have been factors involved I am unaware of. I don't know if we are comparing it with apples, pears or cabbages.
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?
Lots with them per fader/channel
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.
Now that really IS interesting. Clearly rectification et al can be done in the digital domain but can they be done in a cheap PIC?? The obvious way to do it is to sample a 44Kb/s in 16 bits. Can a cheap PIC do this and even if it could, could it then process the data fast enough. To me, this is where you need to think smart about  the information you need to extract and exactly how much data you need to do it. Perhaps that was the subject of your patent??
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.  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.

All other points conceded.

Cheers

Ian
 
Hello,

I started a project with a PIC micro controller
I considered that the cost price in analogue was more important than with the micro controller ...
And the solution is, in my opinion, more elegant.
The point 0 dB can be varied with the potentiometer Vref.
Multiplexing is very easy, and you can have various forms of indicators. Peak, Vu, Vu with peak, etc ...
With another micro controller, you can easily increase the columns ...

Please, let me know your feeling
Cheers,
Pascal
 

Attachments

  • Schematic_2x16.pdf
    56.9 KB · Views: 31
Ian,

Constant current in the entire circuit (and "brightness control") could either be done with PWM'ing on the low side and/or using a current mirror, with the reference using a pot, then using SMD NPN's in place of the resistors on the low side.

Penny transistors are cheaper than $1.65 drivers, if that's all the functionality you're paying for.
 
plimousse said:
Hello,

I started a project with a PIC micro controller
I considered that the cost price in analogue was more important than with the micro controller ...
And the solution is, in my opinion, more elegant.
The point 0 dB can be varied with the potentiometer Vref.
Multiplexing is very easy, and you can have various forms of indicators. Peak, Vu, Vu with peak, etc ...
With another micro controller, you can easily increase the columns ...

Please, let me know your feeling
Cheers,
Pascal

Thisa is a very neat circuit. There are a couple of things you should think about

1. You have two audio inputs Both need A/D conversion. The minimum conversion time (from the data sheet) is approximately 17.6uS so sampling two inputs will take 35.3uS. This is equivalent to a sample rate of 28K bits/sec or a bandwidth of 14KHz? Do you think this is enough?

2. Multiplexing LEDs saves pins but it does mean the peak current in each LED must be increased . However, each port pin can only sink/source a maximum of 25mA. This means your anode drive pins, which drive 8 LEDs cannot provide more than 3mA to each LED if all 8 are on. Since you are multiplexing 4 banks, the average current per LED will be one quarter of this.

Cheers

Ian
 
Rochey said:
Ian,

Constant current in the entire circuit (and "brightness control") could either be done with PWM'ing on the low side and/or using a current mirror, with the reference using a pot, then using SMD NPN's in place of the resistors on the low side.

Penny transistors are cheaper than $1.65 drivers, if that's all the functionality you're paying for.
I got schooled on the manufacturing math last century when working at Peavey.  Inserting 16 $0.01 transistors is not cheaper than inserting one $1.65 IC driver. At Peavey before we bought the vertical  component insertion machine for through hole components ( last century), transistors were hand inserted so even more expensive.  With SMD pick and place everything is machine inserted. Further with microprocessor control you want to conserve I/O lines so serial to parallel conversion might as well include the current sources.

For sensitive audio applications I would advise against driving LEDs with PWM or multiplex for that matter.  FWIW the brightness modulation for LEDs using PWM duty cycle is not as linear as you might expect.

JR

PS: If there is interest I might be willing to share some code sub-routines I developed for the console meter.  I can't share the full schematic because it is a commercial product still in production, and the full software is specific to that hardware, but there is plenty of code that could inform designing a meter, and I own the code. 

for example:
1- rectifier: Capturing AC and then rectifying it in the digital domain throws away one bit of resolution, but saves external circuitry and provides flexibility in post processing the data. The hard part about rectifying the AC signal is determining a stable concise digital AC zero.  I ended up sampling and making the AC zero adaptive , effectively a HPF with very low pole.

2- peak and average with time constants: The peak and average are treated almost identically but just using different time constants.  Peak  attacks at roughly 4 mSec and 200 mSec release, while average both attacks and releases with 200 mSec time constant. The result is a running sum incremented or decremented by a RC time constant factor for each sample.  To mimic a RC with a fixed clock (fixed time interval) routine, a simple multiply of the delta between current sample and running average voltage times a factor generates the exponential RC response. Processor overhead is just one multiply per sample (actually 2 for separate peak and average).

3- meter display. This is pretty straight forward but the running average is compared against X thresholds to light the bar display, the peak running average is compared against the same thresholds to light the dot display.

4- LED drive: The X LEDs get mapped to bits on digital words to represent on/off. These digital words get pushed out for serial to parallel conversion.  The APB meter used HCT Shift registers, now I would use a dedicated LED driver but the serial communication is similar.  I rolled my own SPI routine instead of using the canned firmware because I was having trouble with the 3.3 to 5V logic interface. The slow open drain resistor pull up did not make for very precision clock edges causing squirrely display results until I got it sorted. The modern LED drivers happily accept 3.3v logic, for less drama.

Broken down like that it seems pretty simple... not the thousands of lines of code it actually took.  :eek:

 
ruffrecords said:
Now that really IS interesting. Clearly rectification et al can be done in the digital domain but can they be done in a cheap PIC?? The obvious way to do it is to sample a 44Kb/s in 16 bits. Can a cheap PIC do this and even if it could, could it then process the data fast enough.

Remember the meter range -- you don't need 16-bit samples.  12-bit samples give you 72 dB dynamic range,  which one might consider adequate.  Often you can trade off sample word length sample rate, so grab 8-bit (48 dB) samples and save a couple of SAR clocks and you get a faster sample rate. 

And you don't need to sample at 44.1 kHz or some other standard audio rate. Remember you are not trying to reconstruct the signal. Undersample and let it alias, that information is useful for level even if the signal doesn't "look" correct. That said, the $1.50 SiLabs 8051s have ADCs that run at 200 kHz, which allows you to mix multiple inputs with acceptable sample rates and at a processor clock of 24.5 MHz you have plenty of CPU horsepower to do all of the math. Especially if you realize that you are driving LEDs, which are slow responding things relative to the problem.  Determine how often you want to update the display, and that tells you the time you need to do all of the math.
 
One ting you did not mention JR  is how many bits of data you started with. A regular VU indicates from -20VU. If you want to indicate peaks (say) 16dB above 0VU you need a range of 36dB. With 8 bits, and throwing one away for rectification means accuracy at the bottom of the range will be very poor. 10 bits might just hack it.

Cheers

Ian
 
ruffrecords said:
Thisa is a very neat circuit. There are a couple of things you should think about

1. You have two audio inputs Both need A/D conversion. The minimum conversion time (from the data sheet) is approximately 17.6uS so sampling two inputs will take 35.3uS. This is equivalent to a sample rate of 28K bits/sec or a bandwidth of 14KHz? Do you think this is enough?
I do not recall all the details without checking my old code but one issue with multiplexing the inputs to a microprocessor internal A/D is that there will be a finite settling time when toggling between inputs. If you visualize what is going on when you toggle between a quiet input, and a full scale input, the A/D input sample and hold has to slew as much as 1/2 full scale. This can look like crosstalk between inputs but it is actually related to the S/H settling time. I was toggling between 4 live audio streams and IIRC I grabbed multiple samples at a time, so say 4 samples from input 1, then 4 samples from input 2, etc. This reduced the settling time related ghosting or crosstalk that compromised the meter resolution floor.

Undersampling is not really a problem since we are not reconstructing the digital samples, so aliases that fold below the sample rate will still represent accurate meter levels. 
2. Multiplexing LEDs saves pins but it does mean the peak current in each LED must be increased . However, each port pin can only sink/source a maximum of 25mA. This means your anode drive pins, which drive 8 LEDs cannot provide more than 3mA to each LED if all 8 are on. Since you are multiplexing 4 banks, the average current per LED will be one quarter of this.

Cheers

Ian
The original 8bit PIC I used for my first drum tuner would drive 25mA and I multiplexed an array of LEDs driving high side and low side directly with PIC ports.  You can't pay me enough to work on an 8 bit platform again... the world comes in more than 256 levels. The modern 16bit 3.3v  PIC family I used only has a couple pins that would drive 25ma, most ports are much lower current.

I am surely repeating myself to the point of becoming irritating but I can't imagine not using a modern LED latch driver, allowing any number of LEDs from only 3 PIC port pins for SPI interface. (16 LED latches can be strung in series allowing any number of LEDs that I can imagine).

JR
 
Andy Peters said:
Remember the meter range -- you don't need 16-bit samples.  12-bit samples give you 72 dB dynamic range,  which one might consider adequate.  Often you can trade off sample word length sample rate, so grab 8-bit (48 dB) samples and save a couple of SAR clocks and you get a faster sample rate. 

Accuracy and resolution are as important as dynamic range. You probably need 36dB dynamic range but if you want to accurately indicate -20VU you need several bits at the bottom.
And you don't need to sample at 44.1 kHz or some other standard audio rate. Remember you are not trying to reconstruct the signal. Undersample and let it alias, that information is useful for level even if the signal doesn't "look" correct. That said, the $1.50 SiLabs 8051s have ADCs that run at 200 kHz, which allows you to mix multiple inputs with acceptable sample rates and at a processor clock of 24.5 MHz you have plenty of CPU horsepower to do all of the math. Especially if you realize that you are driving LEDs, which are slow responding things relative to the problem.  Determine how often you want to update the display, and that tells you the time you need to do all of the math.

I don't know about letting the signal alias. Won't the indicated level be wrong?

8051s are much better than cheap PICs which have 8MHz clocks (20MHz with an external clock) which is of course divided down to produce the processor clock. Even so, a PIC should be able to sample a single channel at 44K.

Cheers

Ian
 
JohnRoberts said:
The original 8bit PIC I used for my first drum tuner would drive 25mA and I multiplexed an array of LEDs driving high side and low side directly with PIC ports.  You can't pay me enough to work on an 8 bit platform again... the world comes in more than 256 levels.
JR

I did lots of 8 bit developments in my career including a whole range of label printers. I loved it. I even did an LCD display/keyboard interface on a 4 bitter. (If you have a franking machine with an LCD display you may have seen it).

Cheers

Ian
 
ruffrecords said:
One ting you did not mention JR  is how many bits of data you started with. A regular VU indicates from -20VU. If you want to indicate peaks (say) 16dB above 0VU you need a range of 36dB. With 8 bits, and throwing one away for rectification means accuracy at the bottom of the range will be very poor. 10 bits might just hack it.

Cheers

Ian
I have been messing with this for a while and mentioned the loss of 1 bit to rectification earlier today.

My original drum tuner used a 10 bit A/D so 9 bits of raw dynamic range, my later designs used a processor with 12 bit internal A/D so 11 bits of raw input resolution after rectification.  The RC emulation performing a running sample and accumulate (may not be the correct term for that, I'm self taught) results in more than the raw input resolution from all the averaging of samples over time, while I do not expect accuracy to exceed the raw resolution floor the output display resolution could. I didn't even try because of the settling time issues that limit very low level display integrity. 

master.jpg


The 16 LED display used 3 dB steps so crest factor could be directly read from the distance between the peak and average (VU) bar display... 16x3dB is only 48dB display range (or effectively 8 bits). 

I heard nothing  but positive comments from console owners (albeit mostly second hand, but if there were complaints they would have shared those with me too).

JR

@Ian  I can and did write thousands of lines of code using an 8 bit platform.  The 10 bit A/D output required two bytes. So all processing required extra steps. 16 bit math operations in an 8 bit environment were a PIA requiring multiple clock tics... maybe writing in C could hide some of the data crunching overheard.  I didn't realize how much of a PIA it was until I started writing for a newer 16 bit environment. Never again  no mas.... 8)
 
Back
Top