.
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 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 ...

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 !!

How do you determine if the pulseIn result should be used for a frequency measurement or a TBC measurement ? This turns out to be a relatively simple matter. If the duration of a pulseIn falls between 200 and 1000 microseconds ( 16kHz to 80kHz ), then it will be a portion of a bat call, and the frequency can be determined. On the other hand, if the pulseIn result is greater than 10,000 microseconds, and less than 500,000 microseconds, then it will be more representative of a TBC period. Any results outside of these two ranges should be ignored.

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