LED VU meter

[PRR]

> I always thought RMS was the average and that's that...?

Note that in audio, "Average" is average of the absolute value. A high-passed waveform always averages to zero. That's not interesting. As you said, we rectify (get the absolute magnitude without polarity) and then average. Obvious to analog-heads, but some algorithm-geek may jump right into AVG() and wonder why it don't work.

RMS inherently loses polarity info, no rectifier needed (altho many practical implementations need a rectifier because their "square" is one-quadrant). 

As you know, average is Sum/count and RMS is heating-value. When heating, the high parts count more than the low parts, since heat is square of voltage.

In bench-meters, a $10 meter measures Average, a $20 meter may read Peak-peak. Both are marked (or scaled) so that on SINE waves they read the usually-cited RMS number. The Avg meter has a 1.1 multiplier, my P-P meter has a 1/2.828 divider. But a True RMS bench meter costs $100++, because it has to have a squaring-chip (or heater/thermo) to give actual RMS of arbitrary waveforms. (And even then, any practical True RMS meter has a Crest Factor specification, higher crest-factors won't read right.)

A sine wave is often sold as RMS, the Average is 0.9 times RMS.

A one-sided square wave which is zero V half the time and 2V the other half, averages to 1V, but heats like 1.4V.

Here is a lopsided clipped sine showing Ave about half of RMS.

It is trivial to devise odd waveforms to give odd Avg/RMS ratios, if you enjoy confusing your meters.

However if we high-pass an asymmetrical wave the ratio is different. A very narrow positive spike, hi-passed, gives Avg/RMS near 0.13.

Since DC is not an interesting sound, just makes trouble, we always have some DC-block, a high-pass, somewhere in the chain.

But your singer isn't trying to confound the Avg/RMS ratio. The Avg/RMS ratio of most speech/music will be less than 1 but probably greater than half, and fairly consistent over any long run of mixed music (not pure synth-tones/noises). I would guess 0.8. It isn't very important. Long-term reading of speech/music is inherently sloppy approximation. Level is bopping up/down constantly. And even if we believed that RMS=Volume, I know I could set two different tracks to identical RMS readings, and they would not sound same-loudness.

It isn't precision. When you cut from music to news, or from newsroom to remote, you don't want level to change "much", like -10dB to -30dB. But you can cut-over from -10dB to -15dB and the listener tolerates the level shift. You get the general level generally similar. And an Average will be as good as an RMS except for very abnormal sounds.

 

[livingnote]

Ah, that's great to know. Interesting of all things that heating value is not directly proportional to voltage anymore once you get into AC - like there's more power involved repeatedly backing up your car and then driving forward as compared to cruising on the highway. Does an inertia consideration like this apply to electrons as well? As in, it takes more energy to get them moving than to keep their speed once they actually are on the way (kinda Newton's Cradle-thing)?

I recently built a 120W SMPS and had an interesting problem: We had specified the resistors before the power mosfets at 1 Watt thinking that would do the trick, and they decided to have a grill party instead. Were running at something like 40kHz and kept upgrading them until we ended up with 11 Watters, that at 100 (or 10?) Ohms and I think 24V square wave to hit the mosfets and the toroid with.

The mosfets, òn the other hand, were running really cool making comments like "you gave us such a heatsink for that?"

But for the meter, I see now the trouble in this sought-after precision - what you have is not quite what you see and that isn't directly what you hear, if I understand correctly. But it's close enough for work and you can still implement a precise peak detector to make sure you're not clipping the adc.

Thanks for the theory  ;D Now I just have to build that...

 

[PRR]

> heating value is not directly proportional to voltage anymore once you get into AC

NOTHING to do with AC. You get the same effect with DC.

> backing up your car

No, this applies even if you don't put the car in reverse.

1V in 1R is 1W. 2V in 1R is 4W. Heat is not proportional to voltage but to square of voltage.

On steady DC, yes, peak and average and RMS are all the same.

If the DC varies, peak is higher than average and RMS is somewhere in the middle.

An excellent engine burns 0.4 pounds fuel per horsepower per hour. But the car takes 5HP at 30MPH and 20HP at 60MPH and 80HP at 120MPH, square of speed. So for one hour driving at 30MPH and 60MPH and 120MPH, the time spent at high MPH dominates the total fuel used.

> 1 Watt ... 100 Ohms ... 24V square wave

Well, 24V in 100R is 6.25 Watts, so you would need VERY LOW duty-cycle to survive.

The "40KHz" matters only because you were driving MOSFET gates. If you drove very slowly, 1Hz, you would have very-narrow spikes of gate current and long cooling-off times. However at 40KHz a big MOSFET's gate starts to look like a dead-short. Which is why you needed those resistors in the first place! Instead of your driver trying to supply infinite current for infinitely small time, the resistors limit the drive to 240mA for a longer time (decaying exponentially). Possibly a large fraction of the time. So a large fraction of 6.25 Watts.

If the MOSFETs are really loafing and cold, try smaller MOSFETs with smaller gate capacitance. Heat in MOSFET will go up, because a small-Gate MOSFET has higher ON-resistance. But heat in driver is less due to smaller Gate capacitance.

 

[JohnRoberts]

As usual, a great job by PRR to spell out the differences.

While I still haven't explored the utility of true RMS for audio applications, it seems the deviation from simple average will depend hugely on the character of signal waveform, and time constant decisions made in integration interval for RMS conversion.  Even thermal RMS converters have mechanical time constants associated with heating and cooling a reference mass.

So IMO the bottom line for audio is the difference between RMS and average will be modest, and all over the place for different audio signals. The more complex the waveform (final mix) will be less divergent that more dynamic sources (close mic'd individual instruments).

I suspect dynamics processing, operating on individual instruments may express a slight difference.  This difference may be more important to merchandisers to help differentiate esoteric products from less expensive offerings than to the end users ability to properly manage sources.

Peak vs. ave detection is a big difference, ave vs. RMS, not so much, IMO.

Taking my own advice, if I ever make a high end version of my meter, I would probably incorporate RMS for the marketing hook, more than any practical benefit. 

JR

 

[livingnote]

Ahhh, thank you. Of course, where was me head...V is IR, P is IV = V^2/R.

What we had I remember now was 24VAC turned into what about 32V rectified and filtered DC, chopped up by the mosfets into 40kHz and then hitting a 2:1 trafo to get enough headroom to run 120W load with 2/3 pulse width. But if those resistors limit current to about 250mA going into the primary, how in the world can it suck 7.5 A before the bridge and then pound out 10A at the output? Is there some key thing I'm missing here?  ???

As for the RMS vs. average thing, yeah, I get that with the marketing hook...I was reading "The Red Queen" by Matt Ridley, and he once stated that while Darwin has natural selection, the real driving force of evolution is "sexual selection", as in, just because you're gonna be able to outrun the bear doesn't mean you will procreate - like peacocks with über-big and hugely impractical tail feathers will still have more kids and pass their genes on. So from that point it makes complete sense to design a way complicated and completely unnecessary true RMS detector, as a key sexual attribute to sell the box - to the point where the guy who bought it will start inventing reasons why it's so fantastic to have this function, even if it has no practical import whatsoever...

I was told once how BJ and the Metric Halo guys were perplexed by the Germans who bought their box and were constantly asking for measurements, to the point where the measurements were more important than the sound of the unit - when looking for equipment, instead of doing listening tests they had this habit of comparing datasheets and using that as a reference as to how good the box was. Really interesting how these highly-technical considerations' primary purpose was to cater to the utterly non-technical "my dong is bigger and I can prove it" - thing...this probably runs more of the market than we realize.

So in effect now I will make 3 boards - one a standard average meter with peak hold, one maximum detector for metering a stereo source with one bargraph and one cool bicolor plaything

 

[PRR]

> if those resistors limit current to about 250mA going into the primary, how in the world can it suck 7.5 A before the bridge and then pound out 10A at the output? Is there some key thing I'm missing here?

There's no 10-100 ohm resistor in series with your OUTPUT, your 10 Amps.

Cooked 100 ohm resistors in a switching power supply are likely in series with MOSFET Gates. Some chip or transformer pushes the gates high and low to turn the MOSFETS On and Off. The MOSFETs, when on, act like 0.05 ohm resistors, are passing your 10 Amp load current.

The chip/transformer driving the gates has to swing more than 5V, maybe over 10V, into the Gate. The gate is an infinite resistance in shunt with maybe 10,000pFd capacitance. At 40KHz switching rate, this is a very low impedance and will suck a lot of current.

Imagine a dam, and a lake, and a gate-valve, and a guy who turns the valve to keep the water level constant in rain or drought. If you have a series of wet/dry/wet/dry/wet/dry days, the valve won't wear out, the guy turning the valve may get very tired. Your MOSFETs handle the big flood, but the circuit controlling the MOSFETs gets tired or overheated.

> just because you're gonna be able to outrun the bear doesn't mean you will procreate

No; but if you don't out-run the bear every time until adulthood, you sure won't have any kids.

Yes, when you grow-up without becoming bear-food, you can still stand around the dance-floor and nobody will come close enough to mate. Bear-nibble scars on your butt is a bad sign: you barely made it this far. Giant neon feathers on your butt is a good sign: you have bear-escape skills to spare.

 

[livingnote]

Here we go:

This was the power supply...

And the resistors, after:

The little blue 1/4 watt guys were feeding the gates, and the big ones were in series with the drain. iirc now the big guys were 10 ohms or 11 ohms, and the little guys...what's that? 2.1 Ohms I think?

So the Trafo in the middle had about 15 windings on the primary, not sure how many Henry you end up with...but with 4 mosfets and resistors that would be like 1.75 amps going through each, at 10 Ohms and a guessed RMS of about 18-20V I end up with 30W ?!?! hitting each resistor?

Can I even calculate that way or does most of the voltage drop across the toroid?

One thing for sure, those tail feathers got cooked...

the toroid btw didn't even warm up...

 

[bruno2000]

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.

Very nice.  Please, what is/are the scale(s) in your meters?
Thanks!
Joe

 

[JohnRoberts]

Very nice.  Please, what is/are the scale(s) in your meters?
Thanks!
Joe

I use 3 dB per LED steps so you can directly impute crest factor (peak to ave ratio) by counting the number of LEDs between peak (dot) and VU (bar) anywhere within the dynamic range of the meter.

This meter goes inside a console so the top LED is calibrated for +18 dBu.

There is a switch that allows the customer to select Peak only, VU only, or Peak and VU simultaneous. There is an additional hold on the +18dB peak LED and that peak LED will light, even in VU only mode, so it also serves as a clip/headroom indicator when not monitoring peak.

JR

 

[Rochey]

[and the more modern approach is to use a microcontroller, which these days costs about the same as a 3916]

and use an onboard ADC (which may only be 12 bits or something)
or
take an I2S input and display it on LED's?


Now for some thinking as I go along...
I have 16MHz MSP430's that have serial ports on them. If I run left justified stereo data into it, I get (2*16*44100) bits of data per second.
Thats 1.4Mbits per second.
Running at full speed, that gives me around 11 cycles per bit to do my calculations.
But I can only process one full word at time. So that gives me 362 computational instructions for every sample I have in memory.

Assuming "average" in DSP terms is just a running low pass filter, I need to add my samples to a running tally multiple times, then divide by that multiple.
If each "Add" requires one cycle... then I should be able to average over quite a few samples. Then burn another sample doing the "divide by x number of samples"

ok - my head is beginning to hurt.

/R

/Dafydd

 

[JohnRoberts]

The cheap micro I'm using delivers 14B of A/D resolution, but dynamic range is more limited by crosstalk from S/H settling time when switching between inputs. The good news for meters is you can get away with alternate sampling schemes that would be unacceptable for audio capture and playback. You also pick up some numerical resolution as you average the input data over their time constants.

Adds, subtracts, and multiplies are just one clock tick, and you can do some batch processing where you accumulate multiple samples before performing more complex crunching. The processor speed is not limiting, but I enjoyed a huge benefit from the 16B data path in current micro family I'm using, versus my first proto done on a byte wide processor.

JR 

 

[Andy Peters]

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.

So, over what period does one average?

Or, if implementing a low-pass filter as JDB indicates, what's the corner frequency?

-a

 

[JohnRoberts]

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.

So, over what period does one average?

Or, if implementing a low-pass filter as JDB indicates, what's the corner frequency?

-a

In my very unscientific test I used about 200-250 mSec time constant to integrate the squared sample over time, before performing the square root to convert it to RMS. For the VU (simple average) I used the exact same time constant. The only difference is the square operation before, and square root after for the RMS treatment.

To these eyeballs, on finished music tracks I didn't see any difference.

My memory is kind of fuzzy about my old analog implementations (decades ago) but I seem to recall 20k and 10uF across the integrator opamp for a similar 200 mSec. Of course that could just be a convenient recollection, while it fits.  Back then as now, I targeted a 4 mSec attack on the peak since that was PPM (or one of the several PPM standards). I used the same release times for both peak and VU (same as VU attack) which probably isn't PPM but I wanted the releases to track so crest factor is easier to see. 

JR

PS: I don't know the precise time constant shipping in the consoles now since we tweaked it some by eyeball on the bench, compared to a real VU meter, but I think it's pretty close to my original design target. I'm too lazy/busy to go back and measure, it wasn't trivial to measure directly last time I tried. 

 

[Andy Peters]

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.

So, over what period does one average?

Or, if implementing a low-pass filter as JDB indicates, what's the corner frequency?

-a

In my very unscientific test I used about 200-250 mSec time constant to integrate the squared sample over time, before performing the square root to convert it to RMS. For the VU (simple average) I used the exact same time constant. The only difference is the square operation before, and square root after for the RMS treatment.

Ah, the 200 mS matches JDB's single-pole averager. For those reading at home:

A time constant of 200 mS is d = 9600 samples at 48 kHz. So if

K = e^(-1/d)  then

K = .999

and

a0 = 1 - K  and
b1 = K

so

a0 = .001 and
b1 = .999

which are JDB's filter constants.

-a

 

[Andy Peters]

Ah, the 200 mS matches JDB's single-pole averager. For those reading at home:

A time constant of 200 mS is d = 9600 samples at 48 kHz. So if

K = e^(-1/d)  then

K = .999

and

a0 = 1 - K  and
b1 = K

so

a0 = .001 and
b1 = .999

which are JDB's filter constants.

-a

Ah, OK, so I spent an evening coding this in VHDL for an FPGA-based design. The good news is that the FPGA has a dozen 18x18 integer multipliers which were otherwise unused. Once I remembered which bits of the final filter output were the correct bits to keep after truncation, it works fine. It takes two clock ticks to compute the filter result: one for parallel multiplies and the second to add the products. I suppose I could further pipeline and save a multiplier but there's no need.

So I extended it to eight channels. My audio data come from an octal ADC with TDM-format serial data output, so a natural pipeline exists and I need only one filter entity. The results of each filter operation are stored in a small dual-port RAM, since they are also used as inputs to the filter. Each filter result hits a bank of eight comparators, one for each LED in a meter ladder, so I get a meter display immediately.

Right now I've got the meters driven by eight '595 shift registers, all daisy chained, so the FPGA shifts out 64 bits and hits the common RCLK. Conveniently, I use the converter modulator clock (512 * Fs) as the serial shift clock, so it's all synchronous. This saves FPGA pins, as only two are needed: serial data and RCLK.

A "better" implementation might be to multiplex an 8-by-8 LED matrix and use one '595 for row data and another for column enable. Or I might have enough FPGA pins to drive the LEDs directly. Or something ...

-a

 

[jdbakker]

Ah, OK, so I spent an evening coding this in VHDL for an FPGA-based design.

Good stuff, although I'm more of a Verilog man myself.

The good news is that the FPGA has a dozen 18x18 integer multipliers which were otherwise unused.

For those with less multipliers to spare (or running on a cheap microcontroller), it's worth noting that 0.001 is 'close enough' to 1/1024, or 2^-10. As bit shifts are essentially free in hardware and inexpensive in most processors, this reduces the averager to:

runningAverage -= runningAverage >> 10;
runningAverage += latestSample >> 10;

or

runningAverage += (latestSample - runningAverage) >> 10;

depending on which compiles / synthesizes best on your particular architecture.

JDB.
[admittedly, it's getting hard to find a current generation FPGA without oodles of hardware multipliers. Still, the shift/adds may be cheaper power-wise than MACs]

 

[Andy Peters]

Ah, OK, so I spent an evening coding this in VHDL for an FPGA-based design.

Good stuff, although I'm more of a Verilog man myself.

Having used both, I can honestly say that either is sooo much better than CUPL or ABEL, or god help us, schematics.

The good news is that the FPGA has a dozen 18x18 integer multipliers which were otherwise unused.

For those with less multipliers to spare (or running on a cheap microcontroller), it's worth noting that 0.001 is 'close enough' to 1/1024, or 2^-10. As bit shifts are essentially free in hardware and inexpensive in most processors, this reduces the averager to:

runningAverage -= runningAverage >> 10;
runningAverage += latestSample >> 10;

or

runningAverage += (latestSample - runningAverage) >> 10;

depending on which compiles / synthesizes best on your particular architecture.

The FPGA synthesizer should be smart enough to not even bother doing the shift -- it should simply "pick out the necessary bits." In other words, the shift operation above should be equivalent to (assume 16-bit data, and VHDL):

runningAverage <= "0000000000" & runningAverage(15 downto 10);

If not, the synthesis tool is broken!

[admittedly, it's getting hard to find a current generation FPGA without oodles of hardware multipliers. Still, the shift/adds may be cheaper power-wise than MACs]

My initial thought was to get it working, then optimize. I suppose the multiplier-based case allows for some flexibilty. For example, if one wanted  to change meter ballistics, it's easy to change the filter weights. Dunno if that matters for an 8-LED ladder but if the intent was to do something like a Dorrough, then it's nice. I'm sure the multiplier uses more power than the simple shift but doubtful that it's enough to worry about.

-a