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.

livingnote

Well-known member
Joined
Aug 12, 2007
Messages
1,048
Location
Berlin, Berlin
I'm thinking of maybe designing a stereo PPM meter with peak hold.

What I wanna do is take two 3916s and put them in parallel, with one in bar mode
and standard meter ballistics, the other in dot mode and a slow release to make the peak hold...and so I run into this issue:

I want them all the same brightness, or more exact to keep the current constant to all the LEDs despite the superposition...so right off the bat these would be my ideas:

1. Multiplex them, meaning each LED would get its own little duplexer switching between the bar and dot 3916

2. Strap an OR gate across each LED

Any reason to multiplex rather than gate? I think 2. is probably best...
 
livingnote said:
I'm thinking of maybe designing a stereo PPM meter with peak hold.

What I wanna do is take two 3916s and put them in parallel, with one in bar mode
and standard meter ballistics, the other in dot mode and a slow release to make the peak hold...and so I run into this issue:

I want them all the same brightness, or more exact to keep the current constant to all the LEDs despite the superposition...so right off the bat these would be my ideas:

1. Multiplex them, meaning each LED would get its own little duplexer switching between the bar and dot 3916

2. Strap an OR gate across each LED

Any reason to multiplex rather than gate? I think 2. is probably best...
I don't understand your problem. You will have to use the 3916 in parallel mode, i.e. not in low-current mode (Leds in series), so the current in the Led is determined by the Iset resistor of the chip. Since peak is always higher than average, the dot led will receive its current from only one chip, the one in dot mode.
 
The more traditional way is to use one 3916, and switch its input between peak and average (and its readout between bar and dot). Would that work for you?

JDB.
[and the more modern approach is to use a microcontroller, which these days costs about the same as a 3916]
 
Since peak is always higher than average, the dot led will receive its current from only one chip, the one in dot mode.

Ah. LOL!

*slaps forehead*

I don't quite understand you mean by Low current mode (leds in series), though...

switch its input between peak and average (and its readout between bar and dot)

That's interesting...I hadn't thought about it that way. So I would have one peak and one RMS detector and switch the input between the two with a mux if I get that right, and the bar and dot mode I would just stick +5V and 0 on the second one?
 
Ah, and I was thinking of adding a max(a,b) so that you can stick stereo in a single meter. I was talking about this with dagoose before, we both have one bargraph on our meters for stereo, and I thought it might not be stupid if it just takes the louder channel and indicates that instead of summing first and then metering.

Ah, and for compressors I was thinking of something more elaborate: What if you decide to take those cool RGB LEDs and build a meter that indicates input and output level at the same time? Like, say, blue for input and red for output? Where they overlap you'd get magenta, would make setting gains easy and you'd see the compressed dbs right there on the graph...
 
livingnote said:
I'm thinking of maybe designing a stereo PPM meter with peak hold.

What I wanna do is take two 3916s and put them in parallel, with one in bar mode
and standard meter ballistics, the other in dot mode and a slow release to make the peak hold...and so I run into this issue:

I want them all the same brightness, or more exact to keep the current constant to all the LEDs despite the superposition...so right off the bat these would be my ideas:

1. Multiplex them, meaning each LED would get its own little duplexer switching between the bar and dot 3916

2. Strap an OR gate across each LED

Any reason to multiplex rather than gate? I think 2. is probably best...
There is a simpler way..

Years ago (actually decades ago) I built a prototype of my simultaneous peak/VU meter using a single 3916. I just time multiplexed it between dot mode and bar mode, with some cmos transfer gates to alternately present the rectified peak and average signals to the 3916 input coincident with dot or bar mode. 

If you want to make a peak meter with peak hold you could just multiplex between peak during bar mode and the peak hold in dot mode.

I don't recall the m-plex rate I used but it wasn't very fast maybe 1 kHz?

That was a long time ago and there were better cheaper ways to go back then.. 

JR





 
CD4016  or 4066... simple cheap ways to switch audio signals...  Essentially 4 individual SPST electronic switches in a cheap IC.

It's a little more parts but you could multiplex signals with JFETs or other discrete designs.

JR


 
>Discrete designs

Ah like if you get something that makes two out of phase square waves and sticks them up the corresponding FET's gate?
 
> makes two out of phase square waves and sticks them up the corresponding FET's gate?

The cheap designer will make one square wave, and use a spare 4066 switch plus resistor to make a "NOT gate" to get the opposite phase.

Implementing the gate is left to the student as an exercise.

A CMOS-switch-versus-resistor NOT is slow, but slow relative to the 10MHz possible with full CMOS. Fast relative to the 100Hz-1KHz rate you want to multiplex the two signals.

Hint: 10K is probably a fine resistor here.

Ah, for stereo you want all four switches in a 4066. Consider 4053 which is several 1-of-2 switches, and I -believe- also has level-shifting which may be handy (or moot).
 
Has anybody used the SANYO's LB1412M audio led bargraph driver IC before ?
LB1412M.pdf
12 leds display, has peak hold feature etc
It looks like a cheap solution for led bargraph display (needs only a few external caps and resistors)
I have seen it here:
www.profusionplc.com
at 2.31 euros each (min qty 10), it might not be the cheapest solution, probably one of the easiest though
 
You guys are great.

Yeah, saw that one before and was gonna use it, actually, but I thought I remembered something
like 5 Euros in...but 2,31 heck that's good.

Then again I think I'll build my own little multiplexer just for sports and fun ;)
 
livingnote said:
You guys are great.

Yeah, saw that one before and was gonna use it, actually, but I thought I remembered something
like 5 Euros in...but 2,31 heck that's good.

Then again I think I'll build my own little multiplexer just for sports and fun ;)
Please note that the LB412 does NOT do exactly what you wanted to do in your original plan. The LB412 has only one time-constant, and the hold function just increases the length of time of the highest Leds. The overall appearance may be similar, but the informativeness is not as good. I have an itch this IC is more for ghetto blasters and automotive applications than for serious audio.
 
livingnote said:
Good to know. Yes definitely two detectors are in order, one rms and one peak.

I've been messing with simultaneous peak/VU meters for 30 years (US04166245  Roberts). In a recent design using a microprocessor I developed a code routine to crunch the slow VU level as RMS (not trivial to perform square root inside an inexpensive micro). To my eye, I couldn't perceive any difference between RMS and simple average with music so I reverted to the much easier to implement average detection. Back in my analog days I rolled my own RMS conversion using transistor arrays to perform square and square root computations using the log relationship of Vb-e with current.  But I repeat, IMO it isn't worth the cost and trouble.

Here's a video of my latest meter, used in the master section of a new console. http://www.johnhroberts.com/Candy.wmv
I use the A/D converters in one microprocessor to capture 6 audio streams (4 buses and 2 solo) and did all the crunching inside to drive 4 meters at a time, We send serial data to several SR to latch the output data lines and drive LEDs.

JR

PS: The meter in the video isn't the final release version so there are several minor tweaks, but it's close enough to see the general concept.
 
Microprocessors really are amazing. I have a lot of learning to do...

Interesting, I always thought RMS was the average and that's that, are
we talking about precision RMS vs. just rectifying and filtering to usable specs?

True to the metal, though, are there any ways of finding real RMS with realtime
math in the first place? I mean it's such a complex waveform and all I can
think of is some kind of an exhaustion algorithm, like you take a period, chop it
to bits and then somehow crunch the numbers for the output...but how? All I can
think of are those boxes with the little r that gets heated & measured. I mean I'm
sure it's possible, just...umm...[probably insert a couple semesters here]

Anyway, for practical purposes, I was very satisfied with the little 3916 Full-wave
peak detector, it indicated to within .1-.2db precision in the end, so I think for this
round I'll take the NatSem PPM for dot and their full-wave average detector for bar,
build both out of a texas lightning 074 and dangle my multiplexer off it...speaking of,
should I just grab a kHz multivibrator for the chore or assemble some
astable gate-cap-wiggle-thing with the cmos switches?

Many thanks,

Lukas
 
livingnote said:
Interesting, I always thought RMS was the average and that's that, are we talking about precision RMS vs. just rectifying and filtering to usable specs?

RMS is the Root Mean Square. If your signal has no DC (zero mean), this is the same as its sigma in statistics. The Mean Square (no Root) corresponds to the signal's energy. For real-world nonperiodic signals we can't go summing Squares over all of time, so we must cheat. The most common approaches are to either have a moving window (calculate the Mean Square of the last N samples), or just calculate the Square of the signal of interest (sampled or not), low pass filter the Squares and take the Root of the filter output.

[quote author=livingnote]True to the metal, though, are there any ways of finding real RMS with realtime math in the first place?[/quote]

For most nontrivial signals, what we call RMS deviates from the strict mathematical definition. In audio, we usually don't care -- our sort-of-RMS corresponds reasonably well with perceived loudness.

Practical implementations are possible in the analog domain (see the THAT2252, for example, or through sensing dissipation in a resistor like you indicated) and in the digital domain:

Code:
global int gMeanSquare;
FILTER_CONSTANT=0.001

void UpdateMS(int thisSample) {
  int thisSampleSquare = thisSample * thisSample;

  gMeanSquare = thisSampleSquare * FILTER_CONSTANT + gMeanSquare * (1 - FILTER_CONSTANT);

}

This implements a simple first-order IIR filter to average the Mean Squares, similar to an RC filter in the analog domain. A display procedure would periodically take the root of gMeanSquare and display it. (warning: a practical implementation should deal with integer overflow and fixed-point math for the filter, at least on a floating point-less microcontroller).

Then again, at the end of the day you may find like JR did that a simple averaging of the absolute value of the signal (possibly corrected for DC) is Good Enough.

JDB.
 
Back
Top