StereoBatRecorder

From RevSpace
Revision as of 12:20, 8 March 2014 by Bertrik Sikken (talk | contribs) (Add examples of parameters)
Jump to navigation Jump to search
Project StereoBatRecorder
Status In progress
Contact bertrik
Last Update 2014-03-08

This project is about signal processing of bat echolocation audio recorded through a set of ultrasonic microphones. The goal is to automatically reconstruct the flight direction of the bat.

Knowing the flight direction gives a lot of additional information, like if the bat is just passing or whether it is feeding, getting a better sense where the bat colony is and where the feeding ground is, etc. Having this determined automatically saves a lot of time compared to physically observing the bats in the field at odd hours.

The main principle of determining the flight direction is to measure the time-of-arrival delay between the signals arriving at the two microphones. For example, when a bat is flying from left to right, the first recorded pulse will arrive slightly earlier at the left microphone, with the left-right delay decreasing to 0 as the bat flies directly in front of the two microphones, then the delay will reverse with signals arriving earlier at the right microphone as it flies further to the right.

Hardware

The hardware used is a stereo bat detector that has already been developed, it has the following specifications:

  • sampling rate is 160 kS/s for each channel (left and right).
  • sampling resolution is 8 bits
  • microphone used is the Knowles FG-3329, with useful response over 100 kHz.
  • microphone separation is about 50 mm
  • audio is recorded on an sd-card as a stereo "wav" file, so it can be directly opened in audio editing/viewing software (e.g. cooledit, audacity, raven, etc.)


To get some feeling for the parameters involved:

  • one cycle of a 40 kHz bat signal consists of 4 samples
  • a typical bat pulse of (say) 5 ms consists of about 800 samples
  • the delay between the left and right microphone is about 0.15 ms, or 24 samples

Approach

The plan is to prototype algorithms in a numerical math package (like matlab, octave or scilab), then port the algorithm over to a more high-level language (like C or Java)

Signal processing steps

I expect the following steps:

  • preprocessing: high-pass filter (e.g. 10 kHz) the signal to remove low-frequency noise and make the signal DC-free
  • detecting and isolating the individual calls
    • come up with some metric (e.g. energy in 0.1 ms block) to separate bat sounds from background noise
    • stitching "holes" in a call (e.g. ignore gaps of < 0.5 ms)
    • discarding non-bat clicks (e.g. ignore signals < 0.5 ms in duration)
  • determining the delay between the left and right channel
    • possible methods:
      • direct correlation, can be accelerated by FFT
      • correlation of the amplitude envelope
      • correlation of the frequency slope
      • compare center of gravity of the envelope
    • perhaps switch algorithms depending on the type of call (flat/CF or steep/FM)
  • determine flight direction based on set of delays measured during a pass
    • discard outliers in a smart way
    • consider using the call energy as a weight factor, so clear calls have more significance than quiet ones
  • output the result
    • make a nice graph to visually verify the conclusion made by the algorithms
    • export result to .csv for example

Hilbert transform

An interesting mathematical operation is the Hilbert transform. It allows conversion of a simple real signal into a complex "analytical signal". The analytical signal can be converted into an instantaneous amplitude estimate and an instantaneous frequency estimate. This probably works well for bat signals, since most bat signals are relatively "pure" (doesn't have much harmonics). So, using the hilbert transform, a bat call can be relatively simply separated into an envelope signal and a frequency signal.

Random thoughts yet to be organized

  • I've observed some common pipistrelle bats en-route to use a very flat type of pulse, direct correlation works badly on these pulses. So perhaps use some other type of correlation (correlate on envelope or frequency)
  • a very common source of noise is the sound of car breaks, often between 10 kHz - 20 kHz, partly in the range of bat calls. Can recording containing these be automatically discarded?
  • is it possible to detect that a bat is purely "passing by" (not feeding) by looking at the regularity of the calls?