Audio bar graph. Small!

[Bassman59]

@BrianHG,  how we would get an accurate measurement of the audio envelope with only positive-responding inputs to an ADC in a uC?  Especially when audio waveforms are notoriously asymmetrical.  I completely agree that here in the 21st century we should as much as possible in software.  But I am not seeing how to do that with your average DC ADC?

You have to drive the ADC appropriately. If the ADC has a 4 V span and a 2.0 V offset, your ADC driver has to level-shift the audio up 2 V while likely attenuating to fit within the span. Configure the micro's ADC to give you a 2's complement result, and then the standard absolute-value function gives you a positive result which you can average

Interesting.  Can I just AC couple it with a cap and lift the ADC side with a virtual ground to +2V.  I'm thinking Arduino 10bit 0-5ish volt ADC.

Use your Google. There are plenty of examples of level-shift circuits out there.

Is the difficult bit not then calibrating it?  That virtual ground would need to be very accurate. to get accurate readings or am I over thinking it?  If I make the virtual ground the AREF that might work.

If you want accuracy, you need an accurate voltage reference.

[BrianHG]

@BrianHG,  how we would get an accurate measurement of the audio envelope with only positive-responding inputs to an ADC in a uC?  Especially when audio waveforms are notoriously asymmetrical.  I completely agree that here in the 21st century we should as much as possible in software.  But I am not seeing how to do that with your average DC ADC?

And, sampling the raw waveform would require a much higher sampling rate to accurately catch short peaks which would require a faster (more expensive) ADC and/or uC would it not?

Ok, step #1, looking at the source signals, the OP wants to analyze at least 4 stereo sources, line out, headphones out, line in gain, second line in, that 8 sources.  (Ok, you may be forgiven that since I know this project is designed to fit into his pre-amp with headphone project...)
He wants to save space.  How many op-amp/diode/filter bridges will be needed here?  I still agree using 2 low voltage R-R quad j-fet input opamps, biased to 1/2 vref or VDD in voltage follower mode, series fed through DC blocking cap and 100k or 1 meg resistor.

Step #2, AC biased fed into 8 channel ADCs just means in software, he only needs to read the absolute value of the ADC reading to get a positive only peak info, but we can obviously take this further.

Now to the grunt of your question, processing power.  Take for example a Microchip ATSAM4S2AB in 48 pin QFP, it has 12 bit ADC, 1MSPS, with 8 inputs (definitely fast enough for 8 channel at 44.1khz sampling), running a ARM Cortex-M4+ CPU at 120 mips for 3$.  With this chip, forget silly VU meters, he can run 8 parallel, 256-point full spectrum analyzers in parallel with that small OLED full color display.

Now, if 3$ is too expensive, he can go the Microchip's 1.50$ ATSAMD20G14B, but it's 48mips core but the ADC with 350Ksps, say he can safely sample 6 channels at 44.1khz, or 8 channels at 40khz, and only produce 2 channel 256point fft spectrum analysis.

It even catches me off guard how much can be achieved with a 3$ MCU today with 32 bit, 120 mips as I still look for analog simplification for some designs thinking I have only a few hundred samples/second speed as a limit.  Back in 1988, on my Amiga 1000 with a 7mhz 16 bit 68000, averaging 4 clocks per instruction and an 8 bit sampler on the parallel port, the best we could do was a mono 64 point real-time FFT bar scope on display with a 20khz sample rate.  Today's 3$ MCU with many 32 bit instructions taking 1 clock at 120Mhz, consuming a few ma at 3.3v, with 128k flash rom onboard would run circles around my old favorite computer.

Ok, look, enough said here.  I know a 3$ 48 pin TQFP IC may be too much for some to deal with sampling sound, or how to use a cap ad a DC filter to bias the audio coming in at 1/2 VDD.  All I know it it will take many more parts, board space & give you less opertunity to go with a similar priced or more expensive much slower MCU with slower ADC and work out 8 copies of an analog front end so the MCU samples just a peak signals just to drive a display when the math involved to take the ADC reading and convert it to an absolute value & do any log computation to give you a true peak can be readily adjusted all so easy in software with nothing more than 1 gain figure & 1 decay time value for the meter drop down decay speed.

[paulca]

Brian.  You are always trying to tease me to the extremes.

I am too jaded by my career to be that kind of engineer.  I know the 80/20 rules.  20% the effort gets your 80% the results.  The other 20% takes you at least another 80% of your time and effort.

To be honest I don't think I even have the ability to detect the 20% difference.

This probably flies in the face the standard EE grey beard approach, but for a first iteration of a concept I just want "close".  I don't want to create an audio reference meter that is +-0.5% across all temperatures and bandwidths, I just want to know if I have any signal, if it's a quiet signal, I'm at unity gain, pushing it a bit or flashing red warning lights.

Thus, sampling 3 mono inputs (left channel will do), one stereo master, gives me 5 channels and the sample rate will be whatever I can get an ATMega to do.

[schmitt trigger]

Not a small VU-meter, not a suitable VU-meter for your project, but a beautiful VU-meter design nevertheless.
Using Soviet IV-9 neon bargraphs.

I include it here only as eye candy:

http://www.tubeclockdb.com/non-clocks/332-iv-9-vu-meter.html

Unfortunately the kit is no longer available.

[BrianHG]

Not a small VU-meter, not a suitable VU-meter for your project, but a beautiful VU-meter design nevertheless.
Using Soviet IV-9 neon bargraphs.

I include it here only as eye candy:

http://www.tubeclockdb.com/non-clocks/332-iv-9-vu-meter.html

Unfortunately the kit is no longer available.

Nice!

[BrianHG]

Brian.  You are always trying to tease me to the extremes.

I am too jaded by my career to be that kind of engineer.  I know the 80/20 rules.  20% the effort gets your 80% the results.  The other 20% takes you at least another 80% of your time and effort.

To be honest I don't think I even have the ability to detect the 20% difference.

This probably flies in the face the standard EE grey beard approach, but for a first iteration of a concept I just want "close".  I don't want to create an audio reference meter that is +-0.5% across all temperatures and bandwidths, I just want to know if I have any signal, if it's a quiet signal, I'm at unity gain, pushing it a bit or flashing red warning lights.

Thus, sampling 3 mono inputs (left channel will do), one stereo master, gives me 5 channels and the sample rate will be whatever I can get an ATMega to do.

I didn't mean you had to go to extreme, but, feeding 8 audio lines through a 0.1uf cap with a resistor ad the ADC input to 1/2vdd to the 8 ADC inputs on the mcu, you can make the stupidest 4-5 paragraphs long meter software and it will still work.  The ATMega may still be fast enough to do this as well.  I was trying to get your component and PCB area and assembly cost down to 1 IC and 18 resistors and 9 caps.  How you chose to read the inputs would be up to you, but, you would have 8 balanced equal loads on all your audio sources.  No trimpots, no opamps, and a high enough sample rate that there would be no audible CPU noise fed back to your audio source.

[paulca]

Okay, I starting to see what you mean.

Cap with resistor to "ground" to AC couple and change the level.  Each channel on an ADC pin.  Do the rest in software.  "Ground" being +2V.

You spec 8 channels, interesting.  The rest of the project has been split into modules.  When prototyping I have noticed that individually they form useful boards, but present more options as individual boards.  Things which in the overall project are hopefully fixed can be variable in the sub modules.  In this case making a 5 channel display for a 5 channel project, easily becomes, make an 8 channel display for any project.

It brings me back to MoSCoW.

Must - Must have this time around.
Should - If you can make it happen.
Could - If it presents itself as a side effect.
Won't - Have this time around, probably.

I don't imagine going from 8 to 5 changes the concept though.

[ebastler]

Cap with resistor to "ground" to AC couple and change the level. 

Err, no -- you will need two resistors per channel, connected as a voltage divider between VCC and GND, to set the midpoint of your signal at 1/2 VCC (or where  the ADC's operating range wants it). Then feed your signal to the junction of the two resistors, via a cap.

[BrianHG]

Also, no matter what system you choose, when feeding audio from your pre-amp to your digital PCB, if you will be using series resistors for noise isolation, place those resistors on your pre-amp board.

The 1/2 vdd v-ref bias resistors go on your digital pcb.  (Note, the ADC in the MCU is configured to go from GND to VDD, I would place the 100k on your preamp board near the audio connector leading to the digital VU meter board.  That resistor prevents backward noise and protects the input of your micro's ADC.)

vdd ------------------------
                                 |
                             1meg
                                 |
 audio-100k --- 1uf ----*------ adc pin
                                 |
                             1meg
                                 |
gnd -----------------------

If your ADC is 12 bit, then no sound = 2048.  With a positive signal, this number will increase to 4095, with a negative signal, this number will decrease to 0.

If you want the absolute value:  (This is 50% of you code right here)

LOOP-----------------------------------------------------------------------------------------------------------
(Sample ADC)

 if the ADC >= 2048, then meter_absolute_DC = ADC - 2048
else, meter_absolute_DC = 2048 - ADC

Now, meter_voltage = meter_absolute_DC * CONSTANT-ADC-VOLTAGE-FACTOR

if meter_peak > 0, meter_peak = meter_peak - CONSTANT-METER-DECAY-SPEED
if meter_peak < meter_absolute_DC, meter_peak = meter_absolute_DC

Render meter changes

END LOOP-----------------------------------------------------------------

Well, you can do an 8 channel array sub-loop in the loop, or make the loop sample 1 channel at a time incrementing once each call to gather all 8 meters.
You only need to render meter once every few thousand samples, or, depending on sample speed.
You can average a left and right meter peak together for a mono meter display.
You can put the meter peak through a linear to log, or any db table when driving your display to get a dbv meter.
The sampling loop can be a timer based interrupt call for smooth sampling while the render meter can be continuously drawn to the led's as fast as possible, or on a second timer.

[BrianHG]

Also, you can place a 1nf cap to each ACD input & GND to remove high frequency noise and bounce reading on the ADC.  If you are sampling at 20khz-10khz, change this to a 10nf cap to remove high frequency.

[paulca]

Thanks for the help Brian.  Think I have everything falling together.

Speaking of falling, was I was considering using acceleration for the peak hold decay, but with only 10 LEDs, it won't really be that impressive a feature and probably a constant decay would look as good.  If I had 25 LEDs adding gravity to the peak hold decay would look cool.

[paulca]

That fastest I can get an ATMega to read 8 channels is at 32Khz. Which results in only 32Khz/8 per channel. 4Khz.

This requires setting the ADC pre-scaler to the minimum that would still swing from 0-255 for 0V-5V without error.  There are faster ADC Clock prescalers but there is not enough time for the voltage to settle and they produce errors.

That would leave me using a capacitor on the ADC pins to hold the average voltage... and make the results a little unaware of higher frequency spikes/pulses.  EDIT Actually, a capacitor would only work if I recitified the signal.

It also reduces the resolution to 8 bits.  I might push a few more kHz by using a 20Mhz crystal.

Hmmm.  I'm wondering if the STM32 goes much faster.  Not sure I want to start learning a new micro-controller.  How bad is sampling at 4Khz?

[paulca]

Hang on...

If I spin read one channel at 32Khz for ten samples, then send the max abs value to the display, that gives me 32Khz sampling per channel to detect peaks.  Just not sampled continiously, but taking the average level over a window periodically.

It would give me a display update rate of something like, 320uS, call it 500uS once I write to the display.  All 8 graphs updated in 2ms.

EDIT: In fact as I'm only reading one channel I could probably bump the prescalar up another factor of 2 as I won't be switching between wildly different voltages.  It would mean delaying between channel switches to allow the ADC to settle though.

[paulca]

Ooops.  It's worse than I thought.

I forgot to include the delay caused by Serial.print();

When I print the values, which delays the ADC, I only get to about 2kHz before the channels start cross talking.

[Cliff Matthews]

Time to get more H.P... it's nothing 14usd can't fix and relatively painless (and Danadak would approve..)

[paulca]

I was thinking more about the STM32 which has two ADCs, 16 channels and should be capable of 1Msps.  It's ADC offers a lot more functionality in hardware, such as writing to memory with DMA, auto sequencing, interlacing etc.

It is also quite a bit more complex to set up than the ATMega.

I happen to have an STM32 Blue Pill board so I might have a play with it when the notion takes me again.

[paulca]

I'm getting cold feet on this full rate audio ADC method.

Here is why.  It's going to be a right pain getting 8 channel ADC reads to ensure I get the full 44kHz sampling of each channel.  Not necessarily due to the sample rate of the ADC, but the analog bandwidth of the ADC multiplexer.  With 2 adjacent channels being either muted or at full volume the ADC voltage swing has to be fast enough to swing between a high value and a low value.

It's this limit I am hitting with the AVR, not the outright sample frequency which can go faster.

And lets say I so achieve that, what is going to be the output of this full spectrum audio sampling?  I can't update display at 44kHz, that would be pointless.  So I am going to sample the data at a much lower frequency, like 100Hz by taking the max(abs()) value from 100Hz window.

So I need the peak value within a 1/100Hz period.

This is telling me to implement some form of peak hold on each ADC pin and sample them at a much lower frequency.

A peak hold circuit with a mosfet to reset it.  I can use a 8 channel multiplexer to reset the channels.

Read Channel 1, Discharge Channel 1, Charge Channel 8
Read Channel 2, Discharge Channel 2, Charge Channel 1
....
Read Channel 8, Discharge Channel 8, Charge Channel 7

Then sample them in sequence at a much more modest 800Hz using an interrupt while the display routine runs at 100Hz in the main thread.

It requires a reset-able peak hold circuit on each ADC pin though.  Means analog electronics

Looking at peak hold circuits, it will require 2 op amps per channel, but I was probably going to end up with buffer amps so sink/source current to drive the ADC analog side faster anyway.  Diode drops.  Most of the complaints around speed seem to be referring to frequencies much higher than 20kHz where the charge rate of the capacitor and the current the opamp can supply become limiting factors.

[paulca]

I think this will help me.

[BrianHG]

Funny that your Analog MUX & sampler doesn't do a quick sample and hold.  It would be odd if the 1Mhz ADC was specifically designed not to be able to be used across multiple inputs, including a feature to sample multiple inputs automatically updating multiple registers all on it's own, otherwise, no one would ever be able to take advantage of such a high speed sampler.  It would be silly if using 1 ADC input and an external 74HC4051 8:1 analog mux would work 10x better than using the MCUs internal MUX which should be identical and faster which sounds silly.

Some bandwidth lowering techniques (I guess obsolete since your MCU is too slow): you can series mix L&R to mono by sending the left and right to the same ADC pin after the 100k resistor.  This brings you down to 4 channels to sample.  At the ADC pin, add a 10nf-47nf cap, this bandwidth limits you input to around 5khz (assuming you are using 100k series resistors)  This may still be too fast for your MCU.  I'm so used to using PIC which runs circles around Arduino boards.  Sampling 44k 8 channels is a laugh.

Even the Atmega 120mips chip I listed a page back should run circles around your needs, but, it is always easier to use a MCU you are used to.

[paulca]

It could be my test circuit or interruption of the measurements.

To test it, I ran the ADC in Interrupt enable mode, single shot.  Within the interrupt I increment the channel, increment a counter and start the next conversion.

The AVR does not do auto sequencing of channels and running it in free running mode gives you race conditions with the channel switch, so you can't guarantee which channel you are reading.  The datasheet suggests updating the channel while the ADC is not auto trigger or free running.

In a separate timer interrupt triggered once a second I print, then zero the counter.

I used this for the outright samples per second.

Then to check the values where correct I connected:

ADC0: GND
ADC1: +5V
ADC2: GND
ADC3: Floating
ADC4: Floating
ADC5: 3.3V

Yes I was only doing 6.

... with direct dupoint jumper links between pins.

And checked I got stable and sensible 8 bit values, printing them out in the ADC interrupt routine.

At a clock division of 64, I was getting figures like 254, 0, 254, x, x, 171
At a clock division of 32, I was getting figures like 252, 0, 252, x, x, 168
At a clock division of 16, I was getting figures like 221, 22, 221, x, x, 123 <- effectively randomised by the floating pin.

I thought 16 was the limit, or beyond and took it's Sps of something like 39k.

However, realised the delay introduced by printing the serial values to the screen in the ADC interupt delays the next conversion, giving the ADC sample and hold circuit time to change, the actual sample rate, which was starting to error, was thus, much, much lower.

I tried running the serial at 1,000,000 baud, but that just practically crashed the Arduino IDE and didn't improve much.

This was tested with an Uno clone, not a raw AVR on a breadboard.

[BrianHG]

What happens if you accumulated 1000 samples, then do 1 print?
Isn't the print command way to slow anyways, I mean it has to convert binary numbers to base 10 decimal, then ascii, then all the serial port buisness.  It may have been faster to convert a single set or all in sequence of the 0-256 to 8 levels, sent to 8 leds on an 8 bit io port, + a separate IO pin for a horizontal trigger  & scope it & see it.  If you have a high speed DAC output pin, just push the raw ADC value, you can make on your scope 8 vertical VU meters from left to right on your scope this way.

[paulca]

However, realised the delay introduced by printing the serial values to the screen in the ADC interupt delays the next conversion, giving the ADC sample and hold circuit time to change, the actual sample rate, which was starting to error, was thus, much, much lower.

Hang on.  I was delaying, then changing the channel and immediately reading.  So the effective sample rate would not be that much lower at all.

Still full spectrum sampling digitally will require 352Ksps across the 8 channels, so it won't work on the AVR.

[BrianHG]

However, realised the delay introduced by printing the serial values to the screen in the ADC interupt delays the next conversion, giving the ADC sample and hold circuit time to change, the actual sample rate, which was starting to error, was thus, much, much lower.

Hang on.  I was delaying, then changing the channel and immediately reading.  So the effective sample rate would not be that much lower at all.

Still full spectrum sampling digitally will require 352Ksps across the 8 channels, so it won't work on the AVR.

You only need 20khz/channel.  40khz is overkill and audio frequencies above 10khz are negligible VU meter wise in audio.

[paulca]

What happens if you accumulated 1000 samples, then do 1 print?
Isn't the print command way to slow anyways, I mean it has to convert binary numbers to base 10 decimal, then ascii, then all the serial port buisness.  It may have been faster to convert a single set or all in sequence of the 0-256 to 8 levels, sent to 8 leds on an 8 bit io port, + a separate IO pin for a horizontal trigger  & scope it & see it.  If you have a high speed DAC output pin, just push the raw ADC value, you can make on your scope 8 vertical VU meters from left to right on your scope this way.

I considered this.  Windowing.  Read one channel for T time and display the peak.  Then read the next.

The trouble with that approach is it creates a high pass filter on the meter.  To make sure and get the peak value of a 20Hz signal you have to sample for a 50ms window.  At 200Hz a 5ms window.  Display 8 channels at a sensible update rate would give me poor readings at low frequencies.  5ms*8 channels gives a refresh rate of 40ms, 25fps, which isn't all that bad. 50ms * 8 however is 400ms and 2.x fps, poor.

[paulca]

The peak hold circuit simply moves the job of detecting the peaks out of the uC and into the analog space.  It is the peak detection driving the requirement for high sample rate.  An analog circuit even just a diode and capacitor takes that burden off the MCU for a few pence.   Then I only need to sample and reset those hold circuits at the display update rate.

The opamp gets rid of the diode drop.  (Thanks Dave!).  Most of the other improvements to make it precise probably don't interest me for the application.

It does make it + peak only, but I can live with that.