Bat Detector: automatic recording

Following on from my last post, this one gives revised details of my Pi based automatic recording system.

My original software just didn't work with real bat calls, and the microphone didn't have a very good response at high frequencies. 

But now this has been sorted out I'm getting 10-20 recordings per hour!

background

As mentioned in my last post, it was over 2 years ago when I hooked up an automatic recording system (see this post from summer 2015) to my frequency division bat detector. It was a major gaff to test this system with long duration ultrasonic signals, and then get carried-away with the idea that I could calculate the peak frequency of the incoming signal.

Bat calls typically consist of short duration bursts of sound. So while I could count the number of cycles over a given time period and work out the frequency for a long duration signal, when presented with a short burst during a relatively long capture period, the calculated frequency was naturally much lower than expected.

another approach

So once the penny had dropped I decided to just count transitions (both low-going-high, and high-going-low) and use this information to judge whether the recorder should be turned on. And since the signal often consists of a short duration burst followed by a longer spell of silence, I reduced the sample period down to about 30ms, hoping to grab a short sample and quickly determine if it contained anything interesting.

Public Function SampleFdSignal() As Boolean
'sample the signal from a Frequency Division Bat Detector
'raw ultrasonic signal is divided by 32  intCount = 0
...
  intStartSample = Format(Now(), "ssuu")    'seconds & milliseconds part of time
  For index = 1 To 20000                'equates to about 30ms sampling on a Pi-2
    intState = digitalRead(4)
    If intState <> intLastState Then
      Inc intCount
    Endif
    intLastState = intState
  Next

The Raspberry Pi that I use for this bat recorder is running a desktop operation system (Raspbian) therefore I have to allow for the cpu wandering off to do other stuff, so I use a 50ms timer to trigger sampling to allow some free time between samples.

The number of transitions needed to initiate recording is just a guess. This value can be treated as a threshold or sensitivity setting; too high and I may miss bat calls, too low and I could get false-triggering. The other main change that I made to my original program was concerning recording...

  If intCount > THRESHOLD_COUNT Then
    Event("count," & intCount)
    If IsProcessRunning("arecord") And chkSaveAudio.Value = True Then
      'retrigger timer
      tmrStopRecorder.Stop
      tmrStopRecorder.Start
    Endif
    If Not IsProcessRunning("arecord") And chkSaveAudio.Value = True Then
      strAudioFileName = AUDIO_PATH & "/" & AudioCapture(intCount)
      hRecorder = Exec ["arecord", "-t", "wav", "-f", "S16_LE", "-r", "48000", "-D", "hw:1,0", strAudioFileName]
      lblStatus.Text = "Recording: " & strAudioFileName
    Endif    
  Endif

...instead of just running the recorder for a set time (originally 10s) I now use a second Gambas timer to turn the recorder off about 10s after activity has stopped. This timer is re-triggered by further activity to prolong the recording for as long as necessary. So the recorder will just keep running (i.e. record to a single file) for as long as the bats keep "singing" unless there is a break longer than 10s.

This results in a bunch of recording files of different lengths, and I find myself opening the big ones first!

Recordings need to stop when the application closes.

Public Sub Form_Close()
  
  If IsProcessRunning("arecord") Then
    hRecorder.Kill()
  Endif

End

I also display some timing stuff...

...but this is just required when developing the code.

Location

I have used the bat detector as a manual detector a couple of times this week, outside in the garden (Hey, its cold & dark out there!)

Although I detected bat activity, I didn't see any bats, and the detection was not great. This leads me to think that the bat(s) were following a circuit over neighbouring gardens, which are partially blocked at ground level by our garage & conservatory.

As soon as I brought the detector back inside and operated from a first-floor window, detection improved. This location is well above these low, single storey buildings, and closer to bat flying height. So I think the detector operates over a better range from up there.

I also plan to do some detecting from a front, 2nd floor window which looks out onto the road. I'm wondering whether bats also "hunt" along the street, possibly chasing moths attracted by the street lights.

Bat call analysis

The more I read about it, the more difficult it appears to be to identify bats from these recordings. At the moment I review each recording on Audacity where I both listen to the sounds and look closely at the waveforms.

Some of my recordings sound like a rasping sound, but the more interesting segments sound like "chirps". Apparently, the best way to view them is by a combination of waveform and spectrogram (sonograph).

Spectogram & waveform displayed on Audacity

I've clearly got a long way to go, as my spectrograms look nothing like they are supposed to.

Further development

Although this is an ideal tool for couch potatoes like me (I can lay on the couch in front of the TV while I check the incoming bat recordings via my laptop) I think there is a benefit in operating the bat logger in a fixed position. This is because when I use the bat detector manually outside, I find myself moving between locations, tilting the box up & down, and rotating the device 360deg looking for bats. I probably miss as many bat calls as I detect. However, with the unit in one location and orientation for (say) 1 hour, at least I think I'm carrying out a more sensible survey.

It is getting a bit late in the year and I'd expect bat activity to drop off during October as bats rest-up for the winter. But for next year it would be good to make the unit portable, so I can site it anywhere, run it for an hour or two, and then analyse the recordings.

I would probably use a Pi-zero with a lithium battery, and run a command line version of the current Gambas code, rather than the current GUI app. I also need to try a few recording at full frequency (i.e. take the output from before the divide by 32 chip.

Really useful links

Key to echolocation calls

A guide to analysing bat calls with Audacity