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 the ArduBat.
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
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 ...
In 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