Bat detector

maybe a planar array of microphones summed together (broadside beam) would be an alternative (depending on array gain desired)
Sometimes ... i wished I would hear a bit more bats around my house. Most evenings when I try to test functionality of the batdetector I can hear crickets/grasshoppers and if I am lucky one or two pipistrelle bats. Since all the bats of europe wont come to my house, I can always get recordings of them and use those for testing. So in the code that I am still improving/adapting I have added the option to play 192K recordings of bats as if they were coming in through the microphone. So all functionality of the detector (heterodyne/auto_heterodyne/auto_timeExpansion and Freq_divider etc) is available except for recording the bats. The above image shows how the signal of Nyctalus noctula shows in the new setup (more things have changed :). The 281K marker on the top of the detector is just there because I wanted to stop the replay of the noctnyct.wav file, this means the detector was allready actively listening again. Thats why I also put the gain at 0 ... otherwise you could not see the sweeps of the bat signals.

This should work for any recording at 192K with any ultrasonic sound you would like to test on the detector. Off course you cant test the microphone circuit but you can for instance get used to the - at least for my ears - fascinating sounds of bats in Auto_timeExpansion. We are currently testing this and if it proves to work fine I will update the V1beta with this.

What is that with the display Cor?

It looks much different compared to the v1.0 software...

Well I know of course, and in case you guys did not notice how good the serotine looked in Cor's last message, I attached an image that shows the new vs. the old waterfall image.

I played the same wav file for both software versions.

It is a common pip with feeding buzz, nice hockeystick calls.

I played this using and ALC4050 (384kHz samplerate) audio chip, TDA2030 Audio amplifier and cheap ribbon tweeter.

This image shows the huge difference between the new and old visualization. Looks like Cor put some magic bits in the code.....
There are more call shapes on the display because the pauses are not shown, but the shapes look better an much cleaner. Without showing the pauses we have much more calls to look at and they scroll much slower through te screen.


The update is available as a hex and its a "trial" version. Everything should work as before but the detector-screens will be different and will show the calls more detailed. Next to that if you want to listen to prerecorded bats (or other audio with ultrasound) as if they are coming in through the microphone make sure the recordings are at 192K. Thats the speed the replay will use for these files. I have tried to increase the samplerate for the replay but above 192K the replay is not reliable. Go to menu PLAY, choose your file and set the replay-samplerate to "DIRECT". When you then start playing the file it will be treated as a 192K signal entering the detector. You can switch detectormode, volume, frequency (in HT) with the buttons on the right-side of the detector. Its very likely some of you will find problems, please report these overhere so I can try to solve the issues before updating the main-code.

Hex are at:

PS: bat calls can be downloaded from but need to be converted (eg in Audacity) to 192K samplerate before usage on the teensy_batdetector
Last edited:
Wow...the new waterfall display is an amazing difference. :)

I had two Teensy Bat Detectors side-by-side, one with the new dev software, and one with the previous version, just to see exactly how good the new visualisation is (using an ultrasound source). Can't wait to try it with some real bats...if only warm summer nights in the UK weren't a distant memory.
Last edited:
Did anyone already capture a horseshoe?

I do not have them around here so I played some recording.
I you have a good recording of rhinolophus hipposideros (lesser horseshoe) I'd like a copy.

This is an image of the played recording, recorded on the Teensy bat detector.


You can see a lesser and greater horseshoe.

Beacause of the high frequencies you might want change these lines in.
266 // highest frequencybin to detect as a batcall
267 signal_HiF_bin= int(120000.0/SR_FFTratio);

For the lesser horseshoe values below 100000 are probably not enough.

In TE you also probably need a division rate of 1/20 (TE-speed) or have good ears on 10Khz. And it seems to help to set TE GAP to about 35. If TE

Heterodyne or auto heterodyne do not need those settings and might sound a bet better.
In TE you wil probably only hear something like a continuous tone if TE gap is set 80. In HT you can hear the pauses between the calls a bit better.

I'd like to know if you have some experience on hearing and recording horseshoes and a good highs speed recording of the lesser horseshoe is very much appreciated.


We could make the HiF_bin simply half the samplerate minus 5Khz or so ? Since I dont think at the top of the range will be as sensitive ?

PS: I could also open the startrek version :) With that option you can listen to a beep of 10Khz easily ....
In the startrekversion I chain a heterodyne-mixer after the time-expansion. This allows you to hear the sounds from 0-100000 Khz as a band from -5Khz to 5Khz with the TE_expander on 1/10. Not ideal but fun to do ;)
Instead of changing the HiF_bin (used currently in the detection of ultrasound) its also an option to completely remove the test, the Hif_bin is only used in this line of code of bat_fft.h
if ((FFT_peakF_bin>signal_LoF_bin) and (FFT_peakF_bin<signal_HiF_bin))
changing that line to
if (FFT_peakF_bin>signal_LoF_bin)
should solve any dependencies. This way any signal with a clear peak above the LoF_bin will be detected as an ultrasound sample.
If nobody has a problem with this I will update the code accordingly.

I'm trying to improve the analog amplification of the MEMS
Many test done and not great results ... at least for the audio quality I need.
My Ultramic384k is equipped with a differential amplifier because of the different application fields.
The smaller series of ultramic has a single ended amplification.
The greatest part of application notes and datasheets regarding MEMS amplification report the sensor to be connected to inverting input and this the same as in my Ultramic250k while in this project it is connected to the non inverting input. I don't know which is the best but since the first one has not great result I will try with the second mode.
The main problem is the noise and the frequency response.
The solution is not only to use low noise operational amplifier but all the components and the PCB layout must meet low noise performancies.
In the latest circuit I use LP5907 LDO, this has a very low noise output in the power line: < 6.5 µVRMS.
Just today I found a power management IC that seems to be perfect for all audio application with dual power supply: LM27762. The output noise is 22 µVRMS (related to the output load) but we must consider that the IC has a double integrated switched capacitor converter, the first one double the input voltage and the second brings the doubled voltage to negative level. Two integrated low noise LDO stabilize the outputs.
2-MHz Low-Noise Fixed-Frequency Operation avoids interferences in ultrasonic range (this is very important!!!).
This IC seems to be perfect, the only negative aspect if the small form factor, hard to solder for people with not a great skill with leadless SMD components.
The choise of operational amplifier is not simple since the output inpedance of a MEMS is low and if we want to use a non inverting input then a JFET Op Amp is preferred since the resistor that brings the input to a defined level can be increased with good results on signal.
OPA1642 is low noise, low distortion, jfet Op Amp with Vn at 1 kHz nV/rtHz 5.1
I prefer to avoid an high pass filter, only a decoupling capacitor for DC. Mandatory is the antialiasing filter.
I am designing the new schematic and I will post it soon
Hi Ivano, thank you for letting us know you are working on this. I had no idea it would make much difference to use the inverting or non inverting input of the amplifier. I guess I skipped that part of the datasheet. I agree that it is not easy to build something that is good enough. Most of the time it is functioning well enough but you think it could do better. I am not afraid of small SMD marts but many people are that is why I used all thru-hole mounted parts. A solution could be building the amplifier on the same board as the MEMS so that is the only part that needs to be bought already assembled. Right now the MEMS already is the tricky part, that's why I am selling boards together with the microphone.

If I look at other recordings posted in batcall facebook groups I think we are already doing quite well. I am very eager to see how much this can be improved.

I found you will easilly see the 23khz noise growing if the impedance is not matched, that is why I created a faily low load to half the powersupply. Maybe not a nice solution because it will cost some sensitivity but it kept most bad noise out.

Kind regards,

Yes Edwin, the aim is to do it in the same board and eventually with the same shape so it can be available for everyone. However I can show how to solder the MEMS both with hot air and soldering iron, it's not so impossible to do at home
It is easy to fry your parts with hot air if you are not used solder like that. I always soldered SMD with my old Weller magnastat that I always used with standard(B7?) tip. People think that is huge and showed me their tiny soldering irons. Now with the smaller SMD (0603 and mems) parts I Just recently started using a smaller tip on the trusted old weller.

This is a video of soldering the microphones with 0.7mm resin core solder, no extra flux, the old magnastat with smaller tip and an old hotplate.....

Just an other to do it, temperatures a well under control. The plate usually keeps your coffee pot hot, I found some hot spots on it that make a good soldering machine.

There are a lot of video's around to show you how to solder smd components including the mems elements. If someone want to try it themself check out those video's first. Buy a bunch of microphones and start soldering. The first ones have a good chance to die. I also have some that fail my final test, it is easy to get some flux or solder in the wrong place if you are not careful.

Attached the preliminary schematic, probably there is still some error.
I am going to produce some prototype so we are still in time for changes.
I was thinking that in this way we need to bring the output around 1/2 vdd so perhaps a single supply with the mid reference is the easier solution with a phantom ground at 2.5V since the min supply range is ±2.25 V
Hi Ivano.

I did not read through the LDO datasheet but usually capacitors on the output side of the LDO are larger. Are you sure 100nF is sufficient?
Why the 2v5 regulator and not a voltage divider? Is voltage divider more noisy, or do you do this to consume less current? Just wondering why you decided to do this.

Oh, and what is Vbus? Right now I am powering the detector from a phone powerbank which is about 5volts. I think this should have al least 5.5v input voltage.

Kind regards,

Hi Edwin,

yes, I must add some other capacitor, I usually place 10uF and 100nF in parallel
For very low noise circuit all the voltages must be very stable, so a voltage divider (is not supplied with a unity gain Op Amp) is not completely stable even if you place some capacitor. Moreover it uses less current.
Vbus is the input power = VDD.
This circuit requires at least 5.3V because of the 5V LDO. I never used this configuration but I must check it to see the performancies. Surely the first circuit is better but the output swing between 0V so another Op Amp is mandatory to bring the voltage to ADC specifications. The second swing between 2.5V (bypassing C10)

Two nights ago I tried an FG element in my detector and found is was much weaker than the SPU element, maybe almost like 20 dB lower in my test recording. So I changed some parts in the amplifier and took out the small value capacitors that attenuated the lower frequencies and amplified the higher more so I used big capacitors here.

I went out for a walk, an the detector drove me crazy. Time expansion was triggered many times by crickets and when it did I heard every noise I made walking and rotating controls. My encoders sounded like BOOM BOOM BOOM in the headphones. I did not experience that before. Maybe that was the side effect of amplifying the low frequencies now as well.

What I did notice in the recordings with the FG is that harmonics do not show that easy. Somehow with the SPU I did see the 2nd harmonic like only 20dB below the 1st where the FG has a 2nd harmonic around 40dB below the first.
(Even if I use a similar amplifier circuit as on the SPU element).

Can these stronger harmonics come just from that microphone element?

For now I stil love the SPU element, the FG shows some thin lines in the spectrogram where the SPU does not seem to have these "beeps". Maybe an other aplifier could help.

Oh, I had the feeling the FG frequency response was not as flat as people suggested. A Graph that Cor poined out to me on the avisoft website shows a reasonably flat line. I have the feeling my FG elements picks up muck more low frequencies that the highs. Maybe there is a big difference per element. Hopefully Ivano or someone else has some experience with this.



I know I have no lab conditions but it should be good enough to comepare, you will clearly see the difference. The stronger harmonics is not a big deal, it is still easy to see what kind of bat we hear here but FG looks so much better.

Kind regards,

Hi Edwin

Usually there are few specie of bats emitting vocalization with complex waveform different from the sinewave.
If you see the first or the second harmonics it is due to artifacts when the sinewave becomes more and more closer to a square wave. If you take a look at the spectrogram of the MEMS, the weaker signal at the end has no harmonics, this is due to the lower intensity and the signal comes more close to the original sine waveform.
Another consideration on the MEMS spectrogram is the distortion at the bottom of the spectrogram, surely there is no low frequency signal but there is an artifact like a reflection of the original call.
The FG sensor is more clear even if the signal intensity is lower. The response at low frequencies that you see in the spectrogram is due to something else, not related to the sensor itself. The production of the FG is stable with little difference between the sensors (I tested more than 1000 sensors).
Unfortunately it is not possible to use the same amplifcation for the FG and the MEMS. In my Ultramic384k I use a dual power to supply the op amp and a very low noise differential amplifier, the result is a clear spectrogram with low distortion.
For MEMS I tested many circuits with no great results. Today I plan to produce the prototype of the second schematic so I can tell you if it is good enought. Probably there'll be a rought high pass section with a great amplification over 60kHz with the aim to make the signal response more flat in the higher frequencies.

Hi Edwin

I will build the detector and play around with some parabolic shaped dishes. It will be a good learning exercise. I doubt that these units are using optimum parabolic shaped reflectors. If i cant get it to work with an improvised parabolic reflector I will order a Bird recording parabolic reflector or try and buy a old Sony parabolic mic dish.

I believe that the old HP Delcon 4918A ultrasonic leak detector was sensitive enough to hear power line arc noise, BATS and other ultrasonic sounds as well as ultrasonic leaks without even using a dish.

I will report back when I have some further results.



Edwin has done some good testing and found out that the AUTORECORD is not yet working as planned. This is the case for V1.0 and also for the more recent update. I am currently busy (together with Edwin) to correct the code.

The problem manifests itself very clear but is not predictable. At some stage during autodetect the filecounter (which is used to save files with an ascending number) resets to zero and the code will start writing every next recording to the same file B001_xxx.WAV (xxx=samplerate). This is not as expected and its unclear why this can sometimes happen and especially without a very clear reason. I can mitigate this problem allready (is getting tested) but I hope to find a good way to improve the code to be stable on this.