Gambas Bat Recording Software for the UltraMic + Pi 3

As soon as Christmas was behind me, I found some time to progress my bat detector project.

I've been running the Dodotronic UltraMic with a Raspberry Pi 3 using re-written Gambas code...

...but the problem at the moment is a distinct lack of bats.

Towards the end of last year, I did a few simple comparison checks between my new UltraMic 192k and my earlier system. At that time I was simply using the amplitude of the signal to determine whether the recording should be saved as a possible bat call.

I thought about FFT and reviewed some of the analysis options using existing Linux libraries and commands.

As a result, my latest software is a little smarter, so I don't have to spend so much time reviewing the recordings. Instead of using SoX to return just the 'volume', I'm now using it to give frequency and amplitude data. In Gambas the SoX command looks like this:-

Shell "sox " & RAM_PATH & RAM_FILE_TRIM & " -n stat -freq 2>&1" To strFreqData

This opens my filtered and trimmed recording from the RAM drive and returns two arrays as a string into strFreqData. One is a list of frequencies, the other is the corresponding amplitudes. So in Gambas I search for a data pair where frequency and amplitude are greater than a preset threshold:-

     Do
        strDataPoint = Mid(strFreqData, 1, InStr(strFreqData, "\n") - 1)
        fFreq = CFloat(Mid(strDataPoint, 1, InStr(strDataPoint, " ") - 1))
        fAmplitude = CFloat(Mid(strDataPoint, InStr(strDataPoint, " ") + 1))
        If fFreq > FREQ_THRESHOLD And fAmplitude > AMPLITUDE_THRESHOLD Then
            blnGoodCall = True
        Endif
        strFreqData = Mid(strFreqData, InStr(strFreqData, "\n") + 1)
    Loop Until blnGoodCall

In case you were wondering; if the recording does not contain suitable data, the code just crashes out of the Do...Loop due to the text summary at the end of the recording and then I Catch the error. 

Unfortunately, the combination of the SoX stat command and my data search, can take longer than the recording time; if the software finds nothing of interest (i.e. it has to check all data pairs) then it may take 13-14s for a 10s recording. However, if the search is positive, it may only take a few seconds (i.e. it depends how far into the recording the first instance of a 'good' data pair is).

As Gambas is single-threaded (and working with threads can be a pain) I came up with a scheme to split the work between two Gambas programs. Using a 25MB RAM drive, I wrote a simple program to record from the UltraMic in 10 second segments, which keeps making 10s recordings while there is sufficient space on the RAM drive.

The other program looks for recordings on the RAM drive and processes the oldest. Recordings that exceed the frequency/amplitude criteria are saved to the Pi SD card, while the others are just deleted.

So this solution avoids the complexity of multiple threads, call-backs and signalling between the two programs. The system has run for several days so far without any apparent issues. There is still room for improvement in both the design approach and the programming. But the system seems stable enough to be used over the coming months until I find ways to improve it.

The problem now is a lack of bat activity, so I've had to resort to walking around the garden carrying an ultrasonic cat scarer. But this allowed me to set a sensible amplitude threshold setting.

Although the bat project running in the Queen Elizabeth Olympic Park seems to record bats every night, I haven't detected anything 'Batty' so far over the last 7 or 8 nights. Call me an old skeptic, but most of the QEOP counts appear to be while its still light. I get recordings due to the high frequency harmonics of bird calls (most commonly around 7:30am), so I wonder just how good the QEOP project software is.

Anyhow, unlike my old system, the Ultramic system does not use any batteries, so I'm happy to leave it running 24/7 ...as long as we don't get any rain.