Analyzing Bat Calls...
Using the pulseIn command
|Probably the most
important task that any ArduBat sketch will do
is to look at the Bat Call data pulses and
determine what they mean. I have been doing this for many
years, using the BASIC interpretter built into Parallax's
BASIC Stamp, and in PIC processors running code
compiled with Micro-Engineering's PICBASIC
compiler. Now, I am doing the same thing in the Arduino
environment. Consistent with all of these programming
environments is a PULSEIN function that
looks at a digital input, and determines the pulsewidth
of a detected pulse. This function is, in my estimation,
the cleanest and most reliable way to evaluate the Bat
Call data pulses that the Simple Bat Detector
generates. I felt I needed to dedicate a page to how this
function works within the scope of the ArduBat.
I'm hoping that once you read this page, you will be
confident in knowing what your sketch is measuring with
Syntax of the pulseIn command: ..... pulseIn( pin, value, timeout )
The command is basically saying: Return the pulse duration in microseconds of a value going pulse, found on digital pin pin, that occurs before timeout microseconds passes. The value parameter is set as either HIGH or LOW, indicating whether you want to test a positive going pulse or a negative one. If timeout isn't defined, then it will default to one second. ( You can see the complete reference page for the pulseIn command in the on-line Arduino Reference. ) The result of the pulseIn command returns an integer that can be quite large, and should be saved in an unsigned long variable.
It should be noted that the pulseIn technique is a sampling technique, as it does not measure all of the data that is collected by the bat detector circuit. It does its task only as it is called, and then the processor does other things before returning to the next pulseIn function call. Still, there will not be much that is missed. And don't think that too much time is lost with the one second timeouts. The timeout will occur only if nothing is going on, and the push-button and time checking routines can usually wait for a full second without consequences.
So, what is the pulseIn command looking at in the ArduBat ? The divide by 32 output of the Simple Bat Detector circuit is the signal presented to the Arduino Bat Call pin ( digital pin #2 ). But the pulseIn command is really measuring the duration of only one-half of the complete divide by 32 cycle !
|Look at the diagram to the right...
One complete divide by 32 cycle is composed of one pulse
representing 16 cycles of the original bat call, followed
by an inverted pulse representing 16 more cycles ... and
so on. The pulseIn command will measure only one
of these pulses.
So the pulseIn command is measuring the duration of 16 original bat call pulses !!
Once you have measured the duration of 16 cycles of your original bat call, you might want to know the average frequency that represents. The frequency, in Hertz, of a waveform is defined as ( 1 / duration in seconds ) of that waveform. Since the pulse we are measuring includes 16 cycles of the original bat call, the equation is adjusted to ( 16 / duration in seconds ). Added adjustments to account for the duration being in microseconds, and to give a result in kiloHertz ( kHz ), modifies the final equation to ( 16000 / duration in usec ). So that should explain the source of the frequency calculations that you will find in my sketches.
Even though we can
calculate the average frequency of the bat calls we
detect. How accurate is this calculation ? Is frequency
information from a piezo transducer useful ? These are
important questions, as the piezo transducers used with
the ArduBat have very high sensitivity in a very
narrow range of frequencies. Even detuning the transducer
only provides two or three more narrow bands of
sensitivity. This situation requires an example...
|I usually have bats that fly over my house in the early evenings. I know from experience with other bat detectors that these bats have their strongest call component at about 46kHz ... but the ArduBat logs them at 36kHz ... why is that ?? This is something you need to understand. Below I have made a somewhat crude graph representing the frequency response of a piezo transducer, with and without detuning...|
|The normal frequency response of an
unmodified 40kHz piezo transducer follows characteristics
of the the green plot . The transducer is mostly going to
respond only to the part of a bat call that is in the 40kHz
range. So, the more powerful 46kHz part of my bat call is
not easily detected. Fortunately, bat calls sweep through
a range of frequencies, and the bat would still be heard
at 40kHz. But the resulting ArduBat frequency
will likely look like 40kHz, as the greatest number of
detected samples will be in that range. In fact most of
the bats detected would look like 40kHz bats.
Detuning the transducer gives a frequency response similar to the blue plot. Now we have additional nodes of sensitivity at 20kHz, 35kHz, and 50kHz. Now bat calls will be picked up at more frequencies ... but there are still holes. To complicate matters, the node at 20kHz ( in red ) can be detected as a 40kHz signal, if the signal is overly loud. A strong 20kHz signal causes the transducer to resonate at the harmonic closest to it's fundamental frequency. So, while 20kHz is being detected, it could be represented as 40kHz ... if it is very loud.
|My 46kHz bat is still mostly heard at 40kHz and below .. which is why the ArduBat ends up with a 36kHz average frequency measurement for the bat. So, even with all of the tradeoffs and strangeness of the transducer characteristics, I can still detect my bat, and I get a consistent frequency measurement for the bat, but the frequency I get is not really a complete measurement of the actual frequency of the bat call ... even though it is characteristically accurate for the ArduBat. At least all bats will not sound alike. The variations in bat calls will result in differing averages as the calls sweep through the various nodes of sensitivity. Trying different transducers is one way you can experiment with the ArduBat. I have seen fixed frequency transducers for 20kHz, 25kHx, 32kHz, 35kHz, 40kHz and 50kHz. Combinations of these transducers, will give different results, and can tailor the ArduBat for specific project objectives.|
A bat call sequence is composed of short sweeps of rapidly shifting ultrasound frequency. The greatest amount of power in these chirps is usually at the lower knee of the call ... the area in the blue zone in the graph below. You can see how the upper frequencies in the displayed call are many times not detected. So the high power portion of the call is the part that is most reliably received, and the one that heterodyne detectors are most often tuned to.
|The thing to take away here is that a piezo transducer will often still pick up these stronger portions of the bat calls from nearby bats ... the bats are often very loud. So, keeping in mind the foregoing discussion, collecting the average frequency detected can yield a useful characteristic of the call ... as long as it is consistent.|
|The other measurement that can be made with the ArduBat is the TBC ... time-between-calls of a bat call sequence. In the bat call sequence above, the TBC intervals have been compressed to allow multiple calls to be seen in one plot. If this particular plot was expanded to real time, you would only be able to see one chirp at a time. Below is a bat call sequence of a Myotis ... a bat that has very steep and often rapid calls . This plot has not been compressed, so the TBC could be measured properly if the scale were shown. The ArduBat will also get pulses that represent these intervals.|
|What happens is, the last few pulses of one bat call triggers the start of a pulseIn measurement. After the TBC, the first few pulses of the next call completes the 16 pulses needed for the pulseIn command to complete its pulse. The 16 pulses from the two chirps are very short compared to the duration of the TBC, so don't significantly alter the pulse duration.|
|It would seem to be an easy task to use the pulseIn command to measure this duration and give us an average TBC ... but things are not always that simple. Consider the diagram below, which shows the case of two bats flying together. We would still be able to sample the calls and get average frequencies ... but look at what you would find trying to measure the time between the calls. The times would be all over, depending on which two bat chirps you managed to measure between! The solution to this is to measure TBCs, but keep replacing any prior TBC measurement with the newer TBC ... if it is larger.|
|This will eventually yield the maximum
TBC that can be found in the sequence of calls
being measured. Looking at the two intermingled calls,
you can see that the Max TBC will end up being
representative of the true TBC.
But what if a bat call is dropped in the sequence ... or just not detected ? Then you will have a TBC that is twice as long as it should be ... I'm still working on that one ...
practice, the Max TBC always seems to occur at a
higher rate than would be expected for a given bat. It
seems that my bats will often drop or skip calls. So some
sort of averaging, or other sampling technique may be
needed. As I have said, this is a work in progress !!
It is important to realize that TBC measurements are best made in situations where bats are commuting in open areas, and not traveling though a cluttered environment, or heavily engaged in hunting. Clutter calls, hunting calls, and even calls over water where bats may be drinking, often have greatly reduced TBCs ... to the point where many species will sound the same. So truly characteristic TBCs need to be determined where bats are flying in the open.
TBCs and frequencies that are measured by the ArduBat should let you determine if more than one species of bat is detected over the course of monitoring. They can really be useful measurements, but you do need to understand their limitations. Look for consistency of the results in your application to determine how your measurements should be interpretted. At the very least, if you are detecting both bat frequencies and TBC intervals, at the same time, you can be more certain that it is indeed bats that are being heard.
Be sure to read Frank's ArduBat software page to see an example of measuring TBC's with an interrupt driven technique.
Quick Links: ... Home ... Construction ... Configuration ... the Demo sketch ... Tony's ArduBat Stack
Tony Messina - Las Vegas, Nevada - email: T-Rex@ix.netcom.com