PIC listens audio...

[Vizier87]

Howdy bros.

How would the flow be for this case in PICs (I'm using a PIC18F4455):

1. An audio signal received via an ADC
2. Data transmitted via a 315MHZ RF module
3. Another PIC detects the input and sends it to a PC to be analyzed using acoustic analysis.

The problem with audio is that it is modulated signals, while PIC stores discrete data in binary numbers. How do I transmit audio signals then?

 

[Oznog]

The problem with audio is that it is modulated signals, while PIC stores discrete data in binary numbers. How do I transmit audio signals then?

You're not making a lot of sense. Audio is not "modulated". It's analog. Audio sent via AM or FM radio is modulated. It is entirely possible to transmit digital audio data via radio link, just like any other form of digital data. However, there's a major issue of available data bandwidth.

What bandwidth of audio do you wish to receive? The full audible range, ~ 20Hz to 22KHz- at 16 bits would need 704Kbaud, not counting overhead bits needed to pad and frame the bytes. I don't think your PIC's ADC can sample that fast anyways. A dsPIC's ADC can. It will probably be much more practical to use the remote sensor with a dsPIC and perform whatever FFT or other DSP calcs you need on-chip, then send a summary of the data via RF modem link to the PC. I recommend MRF24J40MA. As a SPI device, it will need a PIC on the other end to bridge to either the serial port or USB, and also manage the link layer.

 

[Nigel Goodwin]

BIG problem is the LARGE amount of data needed (even for crude voice signals) and the tiny amount of bandwidth available via licence free radio modules.

There's also a licencing issue, as sending voice data (or any kind of audio) breaks the licence free conditions.

 

[Oznog]

The module I listed handles up to 250Kbaud, which is a LOT, but still not enough for uncompressed "full quality mono sound". And you probably cannot reasonably compress this much audio in realtime even with a dsPIC.

How does "digital radio" work? Compression. Makes the music FAR smaller. However, you're not going to be doing it with a uC. They (generally) lack the processing capacity, and it's a lossy codec which pulls tricks to avoid audible artifacts in the sound. However, if you're doing technical evaluations like what frequencies a running car engine creates, it'll potentially mess that up in unpredictable ways.

If only a specific, limited part of the spectrum is valuable to you, you could use a dsPIC to translate it to the frequency domain and send the part of the spectrum you need. That's totally workable. Or, do all your data processing on chip and just send whatever specific info it's trying to detect via RF datalink.

I do recommend a codec chip. They're cheap and produce better quality ADC work than a PIC can do. It will save you a ton of work on active filter design for the PIC's ADC. And high quality caps can be expensive. There are speech codecs with a limited bandwidth- like under 4KHz- which may or may not suit your needs- and ones which handle up to the maximum audible range. If your application involves sensing ultrasonics above 22KHz or so, you're out of luck, audio codec chips have hardware filtering built in that keep ultrasonics out of the signal and they generally cannot be defeated.

Alternately, you could utilize an analog AM or FM transmitter/receiver link to send traditional radio signals to the receiver, and only turn it into digital data at the receiver. However, the signal will be vulnerable to noise along the way.

 

[Vizier87]

Sorry folks, it ain't as complex as the music formats, I appreciate the reply.

What bandwidth of audio do you wish to receive?

At what frequency would a raindrop impact give an output on an acoustic piezo disdrometer? I'm supposing it's less than 20Hz.

I do recommend a codec chip

Well I suppose at that level of frequency the best way is to just 'latch' the spike output from the transducer.. So that the ADC of the PIC just takes the output which is the 'freezed' piezo output. It's less complex, and I only wanted to take the approximated signals, since raindrops ain't music.

Now.. how do you do that?

(PS :I'm just doing a wannabe reverse-engineering of the WXT520 6-parameter weather transmitter for my final year project. The disdrometer part is the only one left for me to configure.
WXT520 Weather Transmitter (replaces WXT510) - Vaisala
Attached is the one I constructed. )

 

[Oznog]

Sorry folks, it ain't as complex as the music formats, I appreciate the reply.

At what frequency would a raindrop impact give an output on an acoustic piezo disdrometer? I'm supposing it's less than 20Hz.

Well I suppose at that level of frequency the best way is to just 'latch' the spike output from the transducer.. So that the ADC of the PIC just takes the output which is the 'freezed' piezo output. It's less complex, and I only wanted to take the approximated signals, since raindrops ain't music.

Now.. how do you do that?

(PS :I'm just doing a wannabe reverse-engineering of the WXT520 6-parameter weather transmitter for my final year project. The disdrometer part is the only one left for me to configure.
WXT520 Weather Transmitter (replaces WXT510) - Vaisala
Attached is the one I constructed. )

Ah like the Instructables too.
You really should describe this sort of thing in your initial question. The problem you have is VERY different than what your question implied.

Your sensor should not even be sending audio at all. It should do a simple acoustic analysis on the sound and send a "raining/not raining" or "raining none/lightly/medium/hard/build an ark". At that point the bandwidth needed is trivial.

At what frequency would a raindrop impact give an output on an acoustic piezo disdrometer? I'm supposing it's less than 20Hz.

Well, that's the task before you. I have no idea what kind of piezo signal might be created by a raindrop impact and what is necessary to discriminate from undesired noises.

There's more than latching an edge. An airplane, or someone slamming a door on a building it's attached to. Personally, esp in the experimentation phase, I'd again use a dsPIC so you can take the FFT of the signal. I don't know if that's necessary, but dsPICs are cheap and it helps to have maximum capabilities during experimentation and changing the frequencies evaluated in software are worlds easier than doing it in analog hardware filters. I know "regular" rain sound is a white noise- thus any loud noise which fills one part of the spectrum but not the whole thing- like a Harley driving by- is not rain. But impacts on a physically connected plate, I don't know.

The only downside is that dsPICs have a significant leakage current in SLEEP mode which causes a major problem for long-term battery use. A comparator with a software-adjustable level, and software to reject single, isolated noises- might be all that's necessary and a far simpler and cheaper PIC can do that job.

I still recommend the MRF24J40MA, if the range is acceptable. There's a new variant with a much longer range, at twice the price though.

 

[Vizier87]

Ah like the Instructables too.
You really should describe this sort of thing in your initial question. The problem you have is VERY different than what your question implied.

You know what? Everytime I posted my title as "Disdrometer" , "acoustic Disdrometer" or "Piezoelectric Disdrometer" everyone freaks out, and there'd be one or two replies, and that's it. That's why I didn't want to say the 'D' word first.
The instructables WAS the reason I chose this design. I assumed it could have been about acoustics and hence I thought the problem is about audio. My apologies.

Your sensor should not even be sending audio at all. It should do a simple acoustic analysis on the sound and send a "raining/not raining" or "raining none/lightly/medium/hard/build an ark". At that point the bandwidth needed is trivial.

LOL. I thought my PIC would be too dumb to process such signals, that's why I thought of directly transmitting the readings to a PC to be analyzed. But then you mentioned that fuzzy concept, I might hold on to that, good idea.

Well, that's the task before you. I have no idea what kind of piezo signal might be created by a raindrop impact and what is necessary to discriminate from undesired noises. There's more than latching an edge. An airplane, or someone slamming a door on a building it's attached to. Personally, esp in the experimentation phase, I'd again use a dsPIC so you can take the FFT of the signal. I don't know if that's necessary, but dsPICs are cheap and it helps to have maximum capabilities during experimentation and changing the frequencies evaluated in software are worlds easier than doing it in analog hardware filters. I know "regular" rain sound is a white noise- thus any loud noise which fills one part of the spectrum but not the whole thing- like a Harley driving by- is not rain. But impacts on a physically connected plate, I don't know.

I have observed the output on a scope, and it seems pretty direct. A voltage spike after tapping on it hard/softly. I hope there are no harmonics inside that signal that needs to be addressed though. And what's more, it is quite immune to the surroundings, only reacting to my relentless tapping. The thing is I'm using a PIC18F, so dsPICs are outta my reach coz of resource constraints (you know it..)

That FFT part is going to be possible if I transmit every pulse of the raindrop I received. But since you suggested the fuzzy logic analysis, I'm gonna be delving through that. Just for consolidation, it IS possible to do that ( I mean transmitting every raindrop output) isn't it, with what I have now? (PS interfacing it with electronics not a problem)

I still recommend the MRF24J40MA, if the range is acceptable. There's a new variant with a much longer range, at twice the price though.

That quite pricey from where I come from, dude, but thanks anyway. The 315Mhz module just serves the purpose of it being a proto. I mean, I was gonna use GSM modules (I got sponsor candidates for a GSM PRO) but my professor said "what's the point of doing things which are resolved at it's state of technology when what you need is a cheap working proto?" Made sense to me though.

 

[Oznog]

dsPIC is not a big resource constraint. ICD2 can program and debug them. They're not more expensive really.

The MRF24J40MA is only $20 for a pair... if you don't understand RF links, you may spend quite awhile getting a digital signal across a homebrew system. It's a whole 'nother problem. And the link-layer software for PIC is freely available, fairly straightforward to apply.

Just detecting a level spike is possible... that's a comparator function. It's trivial but may be prone to noise, false audio signals. You need to test the signal by say going onto the roof of the parking garage with a sprinkler can and measure the signal of the impacts on the device on the ground. Then, measure its response to loud noises, airplanes, cars. You need to be able to discriminate. Alternately, a single impact may not imply rain, so it may be helpful to say 2 impacts no more than 30 sec apart constitutes rain. Unless, sometimes you get those big drops in a light rain that initially land a foot apart and may not hit a sensor often. You need to work out these questions. And a measure of just how MUCH rain you're seeing should be important.

 

[Hayato]

With a rain drop falling in a piezo driver, you gonna have a output full of harmonics. Specially in the range of the piezo driver natural oscillating frequency.