Files, Passes, Pulses and Metrics of Activity

How files are saved in CFCread and Analook

In CFCread, there are three parameters which can be set from the Autosave Parameters dialog when interpreting data. These are:

Smooth (deafults to 50)

MaxTBC (deafults to 5)

Min Line Length (deafults to 5)

These same parameters are used elsewhere whenever a continuous stream of Zero-crossings Data is to be broken up into files. An example is when converting a ZCA file (*.zca) to multiple Anabat files. (*.zc or *.??#). Whenever the Autosave Parameters dialog is not offered, so you cannot change these parameters, the defaults listed above will be used. It is my recommendation to never change these parameters. Originally they were offered to allow experimentation with the effects of different settings, but decades go it became clear that the default values work well and there is usually no reason to change them.

A pulse is recognised as a potential bat call if it meets certain criteria:

1) The dots within the pulse must be smoothly connected, which means that each dot must be close to the average of the dots either side of it. How close is decided by the Smooth parameter. Normally, this would be set to 50. You could set it lower if you want only the best quality calls, or higher if you are willing to accept worse calls. But 50 seems a good compromise for most purposes.

2) The pulse must have a length greater than the Min Line Length parameter. This parameter just specifies the number of dots which must be smoothly connected. 5 is usually a good choice, but if you are using a divratio of 8, you could go a bit larger. The tradeoff is that smaller values make you more vulnerable to noise, but larger values increase the likelihood of missing some types of calls (eg feeding buzzes, or short duration, low frequency pulses).

A file will only be saved if at least two such pulses (potential bat calls) are detected within the time set by MaxTBC (in seconds). Usually 5 seconds is a good choice. If only one call is detected within MaxTBC, then no file will be saved. If 2+ calls are detected within MaxTBC, then a file will always be saved.

If a file is to be saved, the file will always start from the beginning of the first pulse detected. When it ends depends on the following criteria:

1) If the buffer is filled, the file will be saved immediately. The buffer can hold up to 16383 data points, which is a fair bit, so this criteria is not commonly met. But noisy files, or files containing many bats could reach this limit. If files contain lots of data and are shorter than 15 seconds, it is likely to be for this reason. Files which have met this criterion will always be large - usually at least 16K.

2) If there has been NO data for MaxTBC seconds, then the file will be saved at this point. This criterion can result in files of short duration, potentially much shorter than 15 seconds. But please note the "NO data" factor. This means absolutely no signal is detected for MaxTBC seconds. To extend this period, no pulse needs to be detected, just any hint of noise or signal at all! If a file is saved based on this criterion, it means the file must be longer than MaxTBC seconds.

3) If the time since the start of the first potential bat call is greater than 15 seconds, the file will be saved at that point. This ensures a file can never be longer than 15 seconds.

4) The file length itself is limited to 32 KBytes, or more recently, 36 KBytes, which allows for an extra 4 KBytes of metadata. It is possible to have data which could contain less than 16383 points but which requires more than the allowance to store. In this case, the file would probably be mostly noise, but it will be truncated when it reaches the limit.

Consequences of this File Saving Strategy

Data can be missed. A single bat pulse in more than MaxTBC seconds will always be missed. However, this needs to be put into perspective. A single bat pulse is rarely identifiable, since there is a much greater risk of confusion between bat calls, social calls or various types of noise, when a sequence contains very few pulses. An important requirement for effective acoustic identification of bats is an extended sequence, usually of several seconds, or at east of several pulses, before an identification can be associated with much confidence. Also, any data missed this way will still be available in the ZCA or DAT file from which the Anabat files are derived. Missing odd pulses like this should not be seen as a weakness in a bat detection system, but for what it really represents - a very slight reduction in achievable sensitivity. For nearly all purposes, the strategy outlined above works very well and does a reasonable job of ignoring small amounts of noise, and any loss of data will have no measurable consequence.
A single bat pass can be split between two or more files. Unfortunately, this is inevitable under some circumstances. Consider, for example, an outflight by a large number of bats, or a bat which stays within recording distance for an extended period. In such cases, the boundaries between files will always be arbitrary, unless the file is long enough to encompass the entire event (as it can be, in the case of a ZCA or DAT file). A less desirable case occurs frequently in passive recordings, because a file from a previous bat pass can include the start of the next pass, but must be terminated before the end of the next pass. This is much more of an issue when file saving is automatic, than during active monitoring, when the user can determine when to save a file, based on the user's perception of when a pass has ended.

Metrics of Activity

A common need is to measure the bat activity at a monitored site, and this requires a metric of bat activity. This could be applied to a specific species, or to a guild of acoustically confusible species, or to all bat species recorded at the site. There are 3 commonly used metrics which can be used for this purpose:

The Pass
The File
The Pulse

The Pass is an arbitrary item meant to represent a single event in which a single bat comes within detection range for a limited time, then moves out of detection range. It is inevitable that nearly all bats will obey this algorithm, but obvious that the amount of time a bat spends within detection range will vary greatly between species, or even within an individual depending on what it is doing. Presumably, the idea behind the pass is that it should correspond to a single event from a single bat, and therefore the number of passes will better match the number of bats generating them. In some cases, this might be true, but in general, it will not. For example, bats leaving a roost in some cases will depart one at a time and move straight past a detector on their way to somewhere else, in which case the number of passes will be a good measure of the number of bats. But more often this will not be the case. One bat can generate many passes, if it repeatedly moves in and out of range, and this should be regarded as a common occurrence over a variety of time scales. In addition, passes of different individuals (or species) can overlap, such as when many bats leave a roost at once. In that case, determining how many bats contribute to a pass can be difficult or impossible. The relationship between the number of passes and the number of bats will depend o many factors which will not usually be known.

It is common to define a pass as a continuous sequence of bat calls separated from other passes by a gap of at least a second.

The File is again an arbitrary item which stores a variable number of bat pulses, also depending on many factors, including the same sorts of variables which affect a pass, but in addition, being more bound to the hardware and software used to generate those files. Obviously, a file can contain recordings from multiple bats of multiple species, and while it would be nice if a file always contained just a single pass and all of that pass from a single bat, there is no reason to expect that.

The Pulse is not an arbitrary item, just a single vocalization from a single bat. There will generally be many pulses per pass or per file, so the numbers of pulses counted will be much greater than the numbers of files or passes.

All these metrics will provide meaningful measures of bat activity. The higher the number in each case the more activity. The relationship between pulses, passes, files and bats will vary enormously depending on bat and detector behaviour, and this will be most affected by the bat species and what it is doing. We can expect that all these metrics will correlate closely within a species and within a range of activities being acted out, and we should expect that over time, the relationship should remain at least meaningful within a species, though it is easy to see that the same species migrating and hunting are likely to show very different relationships. We should not expect the same relationship between different species.

So which is best? Since they will all work, my answer to this is very simple - you should use whatever is easiest! Why waste time counting passes if the natural unit you work with is the file? For example, if you manually identify the species in each file, then the number of files containing each species is easily the simplest metric to employ. Using Auto ID will work the same way if the ID is made on a per file basis. Count the number of files identified as made by each species! On the other hand, if an identification strategy works with pulses, you should use the pulse as your metric. This would be the case if you used filters in AnalookW to identify bats. The pulse is then the natural unit to use.

There is a clear sense in which the pulse is really the best measure of activity. After all, the number of pulses, irrespective of the number of passes or files, does truly represent an unbiased measure of the amount of time a bat spends within detection range. If the number of files or passes per hour remained the same, but the number of pulses per file or per pass varied, then it is easy to see that the number of pulses is the best measure. After all, the more pulses, the more time has been spent within detection range. If a pass contains more pulses, it represents more activity by the bat. This might be compromised a bit if there were a lot of feeding buzzes and those buzz pulses were counted along with the search phase calls, but in practice, feeding buzzes usually contain very different types of pulses and are likely to be treated separately anyway.

Contact Information

To the best of my knowledge, the information in this web page is correct, but I make no guarantee of this. If you use this information, you do so at your own risk, but I am happy to assist anyone with any queries they may have, and will especially welcome any suggestions for improvements, notification of errors etc. Please Email me at:

Email:

Back to: Anabat Technical Notes, Anabat Contents, Home