How to select strongest / loudest signal

[bryce1]

Hi,

could you give me pointers on how to best implement the following:
I have X number of analog (audio) signals. Of those, I want to select the 8 "strongest / loudest" to digitize (signals can change at any time, delay and signal degradation should be avoided).

Is there some analog circuit magic that allows me to do this or do I have to use an ADC for each signal and let a micro look at it?

Thanks!

PS: This is me 

[Rerouter]

sample and hold circuit? e.g. a peak detector with a signal mosfet to short out and reset,

you then measure that with an ADC, (probably through an analog mux if you have many inputs)

[Audioguru]

I simply use my dog. She turns towards and barks at the loudest sound.

[German_EE]

Measuring the signals is easy, SORTING the signals into order so that the strongest are at the top is the hard part. I'm still thinking about this one but the best idea I can think of for now is as follows.

1) Assume 16 signals, it doesn't have to be, I've just picked a number.

2) Feed the 16 signals into a 16 x 16 switching matrix and set the original condition to a 1:1 mapping, A to output 1, B to output 2......P to output 16

3) Start by measuring output signals 1 and 2 and perform a Bubble Sort using the 16 x 16 matrix to slowly move the strongest 8 signals to outputs 1 through 8

Using this method you would only need a dual ADC to compare two channels.

https://en.wikipedia.org/wiki/Sorting_algorithm#Efficient_sorts

[uncle_bob]

Peak detectors introduce inevitable delay, hence it can not do REAL real time selection. The only true real time selection would be using 8 audio digitizers and use software peak detector. Once a peak is detected (with delay X ms), the DSP can concatenate the audio stream with the corresponding channel's buffer, starting from T-X ms. You need a DSP chip that can handle 8 I2S streams and can store a couple of ms of buffer for 8 channels.

Hi

Since it's X channels and you want to monitor 8 of them, you need X digitizers and X buffers. You then select the 8 that you "like" and process them further. One simple approach is to use (say) cheap 8 bit ADC's for the X channels of monitoring and switch the eight (say) 24 bit ADC's around to the channels that are loud. Octal eight bit ADC's are a fairly common item. Far easier to use them than to cobble up a bunch of strange analog stuff. If X is > 1,000 then you might consider some other approaches.

Bob

[Rerouter]

That was why i said a mosfet to reset, in terms of hardware cost, i think that would give the cheapest approach, the OP should have a fair idea of what the frequency content of his incoming signals is, so if he knows its greater than 300Hz, great, then he can check every 150Hz, and make his selections then, and its well below the delays any human can detect,

[uncle_bob]

That was why i said a mosfet to reset, in terms of hardware cost, i think that would give the cheapest approach, the OP should have a fair idea of what the frequency content of his incoming signals is, so if he knows its greater than 300Hz, great, then he can check every 150Hz, and make his selections then, and its well below the delays any human can detect,

Hi

The gotcha here is that loudest quite often is *not* highest instantaneous voltage. A "tick tick tick" can have a lot of voltage, but still not be particularly loud. If you want to sort by what the ear will call loudest, that will take a bit of processing.

Bob

[Rerouter]

Ok got me there, single op amp RMS converter on each input? (Its the next step up in complexity, delivered power),

Yeah refactoring in the human hearing attenuation would require DSP, but i'm unsure exactly how the op needs to approach it,

[Rerouter]

Sorry i haven't stepped into that area myself, so wasn't aware of it, barely half way into ARM,

[bitslice]

I simply use my dog. She turns towards and barks at the loudest sound.

Mine would bark at an orange, I would recommend that dogs be considered obsolete for all new designs.

[uncle_bob]

Ok got me there, single op amp RMS converter on each input? (Its the next step up in complexity, delivered power),

Yeah refactoring in the human hearing attenuation would require DSP, but i'm unsure exactly how the op needs to approach it,

Hi

It's not as crazy hard as it first seems. You can get away with a 8K sample rate and be looking at everything you probably need to analyze. First step are some basic filters to look at the spectrum the way the ear does. (Think A weighted noise ...). After that it is indeed some sort of RMS-ish conversion and a massive downs ample on the result.  What you are building is more similar to an AGC or a squelch than anything else. Process (sum) the power for a while and then feed all the results into a simple voting circuit. Switching channels every 10 us is going to result in utter garbage. I'd bet the rational switch rate (once we finally get told what the purpose actually is) comes out to seconds. 

If it's many hundreds of channels, I'd do this all on an FPGA. It is a highly parallel process and that likely will be the low cost solution. If it's thousands of channels, you probably get into multiple FPGA's or some sort of ASIC.

The dog sitting on my chest (it's a Labrador) approves this message .. slurp ...

Bob

[altaic]

@bryce1 Is there a realtime requirement, i.e. the processed signals must be available as soon as possible? If so, what is the maximum allowed latency?

Also, can you tolerate a bit of delay before you get the desired signal-- basically, is it okay to lose the first 10ms or something when switching between signals? If so, how much loss is permissible?

And, what sound quality do you require as far as sampling rate and bit depth goes?

Finally, what is your budget, and do you plan on volume production?

Depending on your answers, getting what you need can range from cheap&easy to expensive&hard.

[uncle_bob]

@bryce1 Is there a realtime requirement, i.e. the processed signals must be available as soon as possible? If so, what is the maximum allowed latency?

Also, can you tolerate a bit of delay before you get the desired signal-- basically, is it okay to lose the first 10ms or something when switching between signals? If so, how much loss is permissible?

And, what sound quality do you require as far as sampling rate and bit depth goes?

Finally, what is your budget, and do you plan on volume production?

Depending on your answers, getting what you need can range from cheap&easy to expensive&hard.

Hi

I would add to that:

Is X (the number of channels) in the dozens, hundreds, thousands or what?

Is "loudest" simply the instantaneous voltage level or is it as the ear detects it?

Is this a one off or a production design?

Are channel gain issues taken care of ahead of the "detectors" or do they have to handle some dynamic range? If so, how much?

Is this something odd like a phased array of microphones? If so, do vector solutions need to be considered?

How is noise to be treated (rejected) ?

Lots of questions.

Bob

[Chris Mr]

Please think about what 'loud' means.

You could be walking down the street, watching the birds flying around, kids screaming, and suddenly a gun goes off.  You think  I don't live in the US, who is doing this.

On the other hand, you could be quietly listening to the noise from the leaves rustling in the breeze and hear a distant plane go by.

How much bigger than 'normal' does "loud" mean?

[T3sl4co1l]

You guys are jumping the shark here:

What is "loudness"?

If we're talking audio, then it's probably the RMS amplitude averaged over the last 50ms or so (continuous time, not sampled).  That includes the lowest audible frequencies (~20Hz) in the decision, and responds about as fast as you can perceive (any slower and you'll notice that the switching is sluggish).

You may want it slower than that, still.  For example, it's not much use listening to ~50ms of a signal that peaks sporadically.  The shortest snippet that you'd want to hear would be perhaps 100ms or more.

You'd also want hysteresis or a minimum timeout in play.  Just slowing down the amplitude signals doesn't prevent rapid transitions when the signals are very nearly the same levels.  You'll want the signal to hang around a little while, even though it's no longer the loudest signal for those milliseconds.

Also consider, you may not want switching at all.  Simply mixing together the signals, leaves the most dominant signal as, well, the most dominant signal!  But if they're all on similar signal levels, that's going to sound pretty congested.  But suppose you could fade more gradually between them, instead of switching hard.  You'd still generate the RMS amplitude signals, but instead of selecting just one, you send each through a math function first, like a squared weighting function (the audible equivalent of gamma correction!), and use that to control the gain of the respective signals being mixed together.  Weak signals can be faded to quiet and squelched.  A relative decision can still be made (you have to add up the amplitudes and subtract the average-over-all-channels from each, to get the relative intensities).  And if you simply replace "math function" with comparator, you reduce the system to the digital (strict one-of-N) case.

All of this can be implemented with analog circuitry, though you'd be looking at a good piece of anachronistic work to get there (think 70s synthesizer equipment).  Doing exactly the same computations in a DSP would be about as complicated to write, but far cheaper (and more accurate, give or take math and code errors.. ).

Tim

[fcb]

In broadcast audio they use PPM meters (peak program meters) to gauge loudness - Google the PPM meter drive circuit, add one of those per channel, then use your micro to look at the respective analog voltages.

Should be fairly fast, although not the fastest solution possible, probably the simplest.

[LaserSteve]

Google "repeater voter" in ham radio or land mobile radio. it will give you a start, albeit they are two or four channel.

[LaserSteve]

PS, The dog is installed  to bite the operator if he/she touches the mixing board.

[uncle_bob]

You guys are jumping the shark here:

Hi

As usual, we are all trying to help with essentially zero input from the person we are helping....One wonders how important most of these questions actually are to the the people who post them.

Bob

[T3sl4co1l]

As usual, we are all trying to help with essentially zero input from the person we are helping....One wonders how important most of these questions actually are to the the people who post them.

Bob

With the amount of replies seen from such questions, I sometimes wonder if I'm being heard at all... 

But at least I have a good chance of being read by others who can appreciate the thought process, and apply it to other subjects.  So there's that.

Tim

[uncle_bob]

As usual, we are all trying to help with essentially zero input from the person we are helping....One wonders how important most of these questions actually are to the the people who post them.

Bob

With the amount of replies seen from such questions, I sometimes wonder if I'm being heard at all... 

But at least I have a good chance of being read by others who can appreciate the thought process, and apply it to other subjects.  So there's that.

Tim

Hi

I do accept that we create an interesting pile of information for others to sort through each time we do all this. I generally learn a few things along the way as well. My biggest regret is we rarely see what the "real" question behind the question was. Fitting all the information to something real would be a lot more useful than doing it in a vacuum. The guy reading a lot of these ultimately would get the idea that engineering is mostly about debating how many angels can sit on the head of a pin.

Bob

[bryce1]

Thank you guys for the info and also the very interesting questions. I try to make the use case more clear by answering a couple of them:

@bryce1 Is there a realtime requirement, i.e. the processed signals must be available as soon as possible? If so, what is the maximum allowed latency?

Yes, the lower the latency the better. If I have to name a maxium latency, it would be 10ms.

Also, can you tolerate a bit of delay before you get the desired signal-- basically, is it okay to lose the first 10ms or something when switching between signals? If so, how much loss is permissible?

Again, 10ms

And, what sound quality do you require as far as sampling rate and bit depth goes?

12bit, 22khz

Finally, what is your budget, and do you plan on volume production?

Volume production, low figures (sub 1000)

Is X (the number of channels) in the dozens, hundreds, thousands or what?

Max 100 channels

Is "loudest" simply the instantaneous voltage level or is it as the ear detects it?

I would say a combination? So instant switching to the highest voltage level, but only "staying" there if it makes sense to the ear?

Are channel gain issues taken care of ahead of the "detectors" or do they have to handle some dynamic range? If so, how much?

Not taken care of.

Is this something odd like a phased array of microphones? If so, do vector solutions need to be considered?

No.

How is noise to be treated (rejected) ?

Like the plague?

[danadak]

I would think about doing this with a Cypress PSOC.

You have a ton of CPU and Analog resources, fast or slow hi res A/D,
muxes, opamps, coupled with power of software. Not only that a digital
filter in case you need some filtering needs in the signal chain.

Tons of prewritten code, examples, APIs do control it all. GUI design
drag and drop interface. Cheap. Many families, ranging down to sub $ 1.

PSOC 5LP family comes to mind.

https://www.google.com/search?q=psoc+5lp+image&tbm=isch&imgil=1hxaFgAzom4vVM%253A%253B_PaY7Pk8jwcTIM%253Bhttp%25253A%25252F%25252Fwww.mouser.com%25252Fnew%25252FCypress-Semiconductor%25252Fcypress-psoc5lp%25252F&source=iu&pf=m&fir=1hxaFgAzom4vVM%253A%252C_PaY7Pk8jwcTIM%252C_&usg=__AfFRNv0EzE9WtT10uyyWL3O1k3Y%3D&biw=1517&bih=725&dpr=0.9&ved=0ahUKEwiKlMnJtbbNAhVs34MKHcagA9IQyjcINw&ei=X8hnV8roGuy-jwTGwY6QDQ#imgrc=1hxaFgAzom4vVM%3A


Regards, Dana.

[danadak]

Board that you can use -

http://www.cypress.com/documentation/development-kitsboards/cy8ckit-059-psoc-5lp-prototyping-kit-onboard-programmer-and

http://www.cypress.com/products/32-bit-arm-cortex-m-psoc

[uncle_bob]

Thank you guys for the info and also the very interesting questions. I try to make the use case more clear by answering a couple of them:

@bryce1 Is there a realtime requirement, i.e. the processed signals must be available as soon as possible? If so, what is the maximum allowed latency?

Yes, the lower the latency the better. If I have to name a maxium latency, it would be 10ms.

Also, can you tolerate a bit of delay before you get the desired signal-- basically, is it okay to lose the first 10ms or something when switching between signals? If so, how much loss is permissible?

Again, 10ms

And, what sound quality do you require as far as sampling rate and bit depth goes?

12bit, 22khz

Finally, what is your budget, and do you plan on volume production?

Volume production, low figures (sub 1000)

Is X (the number of channels) in the dozens, hundreds, thousands or what?

Max 100 channels

Is "loudest" simply the instantaneous voltage level or is it as the ear detects it?

I would say a combination? So instant switching to the highest voltage level, but only "staying" there if it makes sense to the ear?

Are channel gain issues taken care of ahead of the "detectors" or do they have to handle some dynamic range? If so, how much?

Not taken care of.

Is this something odd like a phased array of microphones? If so, do vector solutions need to be considered?

No.

How is noise to be treated (rejected) ?

Like the plague?

Hi

Ok, If you switch at a 10 ms rate between 100 channels, a small percentage of your channels (think impulse noise) can "take out" the system if you do a voltage level switch. The output to the 8 channels can be a mess. Is this ok? The point being the "make a switch based on voltage, stay based on the ear". That is a fast attack / slow decay approach. The impulse noise is a classic limitation on it.

Where do the 8 channels go? Is there a person trying to listen to the result? If so any switch rate that is faster than they can follow is likely to be an issue.

====

How hard a limit is your 12 bit number? A lot of microprocessors (and now FPGAs as well) have what they call 12 bit ADC's. When you dig into the specs, it can be argued that this or that example is actually a 10 bit or even in rare cases an 8 bit part. It of course depends on just what spec you are looking at. There are parts that will give you a sample in under 1 us. That would let you mux ~ 40 channels into a single ADC. The processing of the result would then be an FPGA sort of thing. It probably works if 12 bits is a loose number, maybe not at the 40 channel level if it's full spec sort of number.

====

If you head into an FPGA solution, it likely becomes a time shared filter to do the band limiting. The signal to power conversion stuff is fairly straightforward. None of it is likely to take a ton of DSP blocks on 12 bit data. Does it fit in a $3 part or a $10 part .... that depends on some of the stuff above.

Bob