Bat Detector - 96khz sample, FFT and iFFT?

Status
Not open for further replies.

DrMikeG

Active member
So, the bats that live in my garden (and scare my Son) make calls in the range 20-60khz.

I have an adafruit electret microphone, which is spec rated up to 20khz, but I've heard can give some response 'up to 60khz'.
I have a teensy 3.1 (which is amazing!)
I have a adafruit mono amp and speaker.

I've worked through various examples, I just can't quite fit all the pieces together, so I'm asking for advice.

Plan:
1) Record a buffer of audio from the microphone as fast as I can (ideally 96khz+)
2) FFT the audio - identify if there are any signals in the 20-60khz range - if not, chuck away sample and recollect.
3) Shift the frequencies down to an audible range
3) iFFT the data to recover the shifted audio signal
4) playback the data (so you can hear an audio representation of the bat call)

I started working with the adafruit 'fun with FFT' tutorial (https://learn.adafruit.com/fft-fun-with-fourier-transforms/overview-1), which is very helpful - but this is based on a microsecond delay for the sample collection timing, and I don't know how to rewrite it to collect samples faster.

Today, I discovered the Teensy Audio library, which also has a great FFT example - but I don't see an inverse FFT offering? (I understand arm library can do it)

I still need to up the sample rate from 44khz to 96khz (mono, happy to sacrifice a few bits of quality).

So, can anyway offer any advice on:
1) Sampling at 96khz
2) Inverse FFT in Teensy Audio library

All other comments and suggestion welcome.:D
 
1) Sampling at 96khz

A few people have tried higher sample rates, with some degree of success.

However, 96 kHz won't be nearly enough for a signal that has 60 kHz bandwidth. Everything from 48 to 60 kHz will alias, ruining the rest of the signal from 32 to 48 kHz.

2) Inverse FFT in Teensy Audio library

You'll need to dig into the audio library code. Inside the audio lib, the ARM math lib is used to do the actual FFT. The FFT's complex numbers are turned into magnitude-only real numbers. At the very least, you'll need to remove that magnitude code and double the output buffer, so you can preserve the complex output.

The good news is the ARM math library has inverse FFT, so you should be able to do that part if you're able to dig into the library code. There's some limited documentation on the website about how the library and objects work. Maybe it'll help?

http://www.pjrc.com/teensy/td_libs_AudioNewObjects.html
 
Thanks for the response Paul, I'm honored :)

I've just found the thread discussing Pedvide's ADC library - I'd better have a read though that too before I post any more questions.

Thanks for the pointers.
 
So, the bats that live in my garden (and scare my Son) make calls in the range 20-60khz.

I have an adafruit electret microphone, which is spec rated up to 20khz, but I've heard can give some response 'up to 60khz'.
I have a teensy 3.1 (which is amazing!)
I have a adafruit mono amp and speaker.
I don't know which species is in your garden, but some bats echolocate at frequencies that extend up to 200kHz. so a normal audio microphone may not be suitable.
have a look at http://www.wildlife-sound.org/equipment/technote/micdesigns/index.html for an alternative ultrasonic microphone using a Panasonic WM 61A

I've worked through various examples, I just can't quite fit all the pieces together, so I'm asking for advice.

Plan:
1) Record a buffer of audio from the microphone as fast as I can (ideally 96khz+)
2) FFT the audio - identify if there are any signals in the 20-60khz range - if not, chuck away sample and recollect.
3) Shift the frequencies down to an audible range
3) iFFT the data to recover the shifted audio signal
4) playback the data (so you can hear an audio representation of the bat call)
keep in mind the bat signals are very short, typically 1 to 10 ms (or for CW bats up to 100 sometimes 300 ms). So, depending if you only wanted to hear the bat clicks and do not wanted to carry out bioacoustics research, an envelope detector is all you need. (commercial bat detector work like that). Then you don't need FFT based down-sampling.
So, can anyway offer any advice on:
1) Sampling at 96khz
2) Inverse FFT in Teensy Audio library
so my advice is
sample the microphone at 192 kHz for signals up to 96 kHz, run a envelope detector ( I can help) and put the output into DAC.
If you wanted to experiment, you could try to clock the PJRC audiocard at 192 kHz (quality uncertain) or get a 192kHz audiocard.
 
Hi WMXZ - thanks ever so much for your input!

You are quite right, there are certainly bat call frequencies which will be way above what I can reach - and I'm not a bat expert, but I am an optimist. I did read that some bats here in the UK have calls that sweep down from 60khz-20khz, so that's what I am aiming for.

The basic adafruit electet microphone package I've picked to start with, because it was cheap, and it uses a microphone with very similar documented specs to the Panasonic WM 61A (which I believe is now discontinued) - it will be interesting to know whether it has similar undocumented properties (i.e behaviour above 20khz). If I can get the processing side of things working, then I'll know if the microphone is the weak point :)

I need to read up on the envelope detector - but this sounds like a good place to start.

I've not finished reading/understanding the ADC thread about the sample rate limits of the teensy 3.1.

Thanks
 
I need to read up on the envelope detector - but this sounds like a good place to start.

It is all about experimenting.
A simple envelope estimation is based on what is called the Taeger-Kaiser Operator which is simply
Code:
I1(k-1)= x(k-1)*x(k-1) - x(k)*x(k-2)
It acts as a 2-tap band-pass filter, gives the intensity of the envelope for frequency at a 1/4 of the sampling rate.
It is fast but if you need it still faster, you can approximate by
Code:
I2(k-1)= (x(k)-x(k-2))*(x(k)-x(k-2))
note: all results are not causal (use sample in the future) and I2 is twice the value of I1
 
Last edited:
Doing that with FFT and IFFT looks a bit like an overkill for me. 2 analogue filters (input and output), an oscillator and a ring modulator should do the trick. But perhaps I'm just too old... ;-)
 
Hi Theremingenieur.

Thanks for the input - I think what your suggesting is broadly the 'heterodyne' technique, which would produce a series of clicks?

With the FFT, I can theoretically synthesize a slowed down, audible version of a bat call - although with all the economies I'm taking it's more likely to end up just sounding like circuit noise :)

Thanks
 
Yes, I was thinking about heterodyning. :)

If you want a slowed down variant, there would still be the idea of recording the input signal with a high sample rate and playing it back with a lower rate. It's not that I oppose to using FFT and IFFT (I'm a mathematician), but I always look for a way which consumes a minimum of resources. Call me old-fashioned, but I've grown up in a time where valves and transistors were expensive, thus one had to find tricky ways to get out the maximum of each of them, for example using the same device as an oscillator and a mixer and a AGC stage...

Today, we have a transistor inflation, millions of them in a single chip, that's true, but that doesn't still prevent me from looking for smartly optimized solutions.

In Austria, they say: Don't take a sledgehammer to crack a nut...
 
Oh I'm also totally in favor of simple solutions - but if I'm going to slow the signal down, I need to only play it back selectively?

If I'm playing back at 1/10th speed, I can only play 1/10th on the input in real time.

The DSP would hopefully allow me to identify which 1/10th has something worth listening to.
 
Oh I'm also totally in favor of simple solutions - but if I'm going to slow the signal down, I need to only play it back selectively?

If I'm playing back at 1/10th speed, I can only play 1/10th on the input in real time.

The DSP would hopefully allow me to identify which 1/10th has something worth listening to.
Again, keep in mind bats use very short echolocation clicks (very stereotyped and boring) and not tonal /pulsed and interesting calls like birds.
so, you will only hear short clicks, with variable repetition rate.
The fun listening to bats is to hear how they change their echolocation rep rate when approaching targets (typically flying insects)
 
It is all about experimenting.
A simple envelope estimation is based on what is called the Taeger-Kaiser Operator which is simply
Code:
I1(k-1)= x(k-1)*x(k-1) - x(k)*x(k-2)

That's really interesting. I'd never heard of this operation until now.

I've always considered envelope detection to be absolute value of the signal, feeling a low-pass filter, where the filter state is instantly set to the signal amplitude if it's greater.
 
Again, keep in mind bats use very short echolocation clicks (very stereotyped and boring) and not tonal /pulsed and interesting calls like birds.
so, you will only hear short clicks, with variable repetition rate.
The fun listening to bats is to hear how they change their echolocation rep rate when approaching targets (typically flying insects)

Thank's WMXZ. I know very little about bats - I'm basing this work on the information here (nice example processed sounds) http://www.skillbank.co.uk/bat_detectors/tech.html

The echolocation rep rate would be very interesting to listen too - but I'd def. need some storage, maybe the SD card on the pjrc audio board?). That would have to be the next phase of this project, and I am time limited because the bats can start to hibernate around here next month...


So, my task when I finish work today is to write a sketch to continuously read from the ADC to a buffer, and when the buffer is full, to play it back unaltered using the DAC...
 
That's really interesting. I'd never heard of this operation until now.

I've always considered envelope detection to be absolute value of the signal, feeling a low-pass filter, where the filter state is instantly set to the signal amplitude if it's greater.

As I understand it, the envelope is the magnitude of the analytical (Hilbert transformed) representation of the real valued signal.

LP-filtered absolute squared values (need square) gives you the RMS squared, which is 3dB below the envelope.
Don't know what LP-filtered absolute values give.

Now, the Taeger-Kaiser is made to give you the intensity of the signal and intensity is envelope squared (right?).
People call it also TK energy operator. It is close to the true envelope squared for signals at fs/4. It is good enough and widely used for a click detector in bioacoustics.

The derivation is simple
Code:
x(t)=A*cos(om*t)
x(t+dt)*x(t-dt)=A^2*cos(om*(t+dt)*cos(om*(t-dt))
                  =A^2*(cos^2(om*t)-sin^2(om*dt))
or
A^2*sin^2(om*dt) = x(t)*x(t) - x(t+dt)*x(t-dt)
the sin term to the left becomes 1 for om*dt=pi/2 or fo = fs/4 (fo signal fs sampling frequency) and the right side becomes the amplitude (or envelope) squared

The only problem I have with TK that the subtraction may give you from time to time negative values. but it is fast.
 
Ok, so I've been trying to do too many things this evening, but I did have some time to look at this.

Having got a better handle on setting up the ADC, outputting analog, and the FFT, I've got the beginnings of what I wanted.

Sorry, I don't have a fancy digital oscilloscope or a tone generator, so you'll have to make do with a Heath Robinson setup and a video shot on my ipad.

https://drive.google.com/file/d/0B3ii0SYsImfsWHNqaHJSQmp1c28/view?usp=sharing

(That link might work...)

If you can see the video, what you can see is Tony Dicola's excellent Adafruit FFT tutorial. It includes a Spectrogram program written in python that is visualising the results of the FFT.

The grey hockey puck is an ultrasonic mouse deterrent (I had one of these in the attic, although it wasn't doing anything as the battery was flat)
I'm resting the microphone right on it.
I'm capturing from the ADC at 122000hz (any higher and it crashes - don't know why yet).
I'm FFT'ing the data, which allows the Spectrogram program to function.
Then I'm iFFT'ing the data, and playing back (something) via the DAC to an amp/speaker at 1/10th of the sample rate.

Whilst I have a plausible result, I'm fairly sure I'm doing some of these steps somewhere between slightly and very wrong...

Can I tidy the code and post it here, and perhaps people would be kind enough to tell me what I've got wrong?

Thanks.
 
Last edited:
So, I have a rather basic question...

If I attach my microphone / preamp to my teensy with really long wires (say, 2 meters) will it have any appreciable effect on my circuit?

Can I dangle it out the window?
 
So, I have a rather basic question...

If I attach my microphone / preamp to my teensy with really long wires (say, 2 meters) will it have any appreciable effect on my circuit?

Can I dangle it out the window?

As always, it depends
A preamp usually converts to low impedance to cover long distances.
However, long wires are good antennas.
To counter external interferences (e.g radio waves, cell-phones etc) preamp should drive differential lines.
But you may play with thin coax cables to shield. proper grounding is then key.
 
If I attach my microphone / preamp to my teensy with really long wires (say, 2 meters) will it have any appreciable effect on my circuit?

Musicians and the entertainment industry have been using microphones with long wires for over 50 years. Plenty of knowledge and experience has built up, regarding the right and wrong ways to use microphones. Details matter!
 
Musicians and the entertainment industry have been using microphones with long wires for over 50 years. Plenty of knowledge and experience has built up, regarding the right and wrong ways to use microphones. Details matter!

Hi Paul, thanks for the input, but do you mean you'd need me to provide more details of the circuit before you could comment on whether the wire length would necessitate a change?
 
Thank you again WMXZ, I'll have a read.

Please don't have the impression that I'd not already tried google - but without the magic phrase "grounding single ended audio connection", there is an awful lot of Internet to read on the subject of 'proper grounding'

Many thanks
 
I'll jump in, although I haven't looked to see what characteristics the microphone you are using has.

The difficulty with long wires and a (likely) weak microphone signal is mostly picking up RF -- AM (medium wave) radio usually. If the microphone can drive the capacitance of long wires, then the best approach is twin shielded cable -- this has wires inside a braided shield. Connect the shield (at one end only) to the GND of Teensy. Connect one of the other (inside) wires to GND also at the Teensy. At the microphone, connect the 2 inside wires. Do not connect the shield, unless the microphone also has a shield that is not connected to the other 2 wires.

This will shield you agains the RF, but you'll only get an audio signal if the microphone can drive the capacitance of the long wires.

You could use a single shielded cable (shield -> Teensy GND, other wire -> ADC; at the microphone connect shield and wire), but that will not be as good for RF elimination.

In either case, you might find that RF filters (like the plastic-coated ferrite lumps that you see one USB and other cables) might be helpful -- at the Teensy end. Sometimes you can get get one by removing from a wire if it has removable plastic clips.

If the microphone has a weak output, nothing will work -- you'll need a preamplifier. Sometimes electret microphones already contain an amplifier (and need a DC bias/power supply -- which can be supplied along the shielded cable, but needs some isolation at the Teensy's end).

You may find that 'audio' microphones and amplifiers cannot drive the capacitance of long shielded cables.
 
Status
Not open for further replies.
Back
Top