AudioMoth Configuration App 1.3.0 & Firmware 1.4.0

@jfgodeau The next version of the firmware and configuration app, due in a couple of weeks, allows you to set a minimum trigger period so that at least x seconds are written to SD card after each trigger event. There are also more tools to allow you to expand and split the resulting files.

The previous battery voltage measurement used an assumed microcontroller voltage of 3.3V. This works well when the battery is above 3.6V. However as the battery voltage drops, the processor voltage drops, and the battery voltage becomes inaccurate just when you actually need it to be as accurate as possible. In version 1.4.0 we use another microcontroller channel to measure the internal voltage and then measure the battery using this measured reference. This makes the voltage measurement more accurate and is the one that is used in the WAV file headers. We also use this internal voltage measurement as the cut-off voltage and keep making recording until this falls below 2.8V. This gives enough margin to stop make recordings before the voltage gets low enough that writing to the SD card become unreliable (below 2.7V).

Thanks Alex,

I guess it will have to be custom firmware for my project then.

In any case the 1.3.1/1.4 combo is a great help for my other uses of AudioMoth.

Hi Alex, Thank you, but I've tried what you say, without the batteries, with the same paper clip I just used for the other devices, but something goes wrong with this device, I don't know what. Is there a specific ammount of time that I should press the clip against the contacts?

@Francisco Rivas No specific amount of time. It just needs to be connecting the contacts at the same time as the power is applied, so that it powers up and immediately finds the contacts connected together.

Following the instructions in the Flash App to under 'Show Manual Switch Instructions' option will bring it back. You need to power it up in bootloader mode which means removing batteries, holding the paperclip in place, and then plugging in the USB cable. It's a bit fiddly but will work in the end. You can't damage the AudioMoth in the normal flash operation - the bootloader is still intact and the process above will power it up running the bootloader even if the application has only partially been written.

@Alex Rogers That’s exactly what I did —several times- but didn’t work. The flashing app doesn’t find the device.

@John Connock This is the unix command which should also work in PowerShell:

hexdump -C -n 488 20200602_180000.wav

I'll write an R script for this tomorrow.

@Alex Rogers Thanks, will be looking forward to the R script.

@John Connock I am having the same problem but it's related to the version of Powershell on my system.

According to: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/format-hex?view=powershell-7

The -Count option was introduced in version 6 , while my system is 5.1.18xxx.

You can check your version number with this command at the Powershell prompt:

Get-Host | Select-Object Version

So I think we will have to upgrade our versions of powershell, before Alex can help us.

If you can use R on linux, the following hacky function will get you the temperatures:

get_AM_temperature <- function (t_file_name) {

  if (!file.exists(t_file_name)) {

    t_err_msg <-  paste0("File: ",

                         t_file_name,

                         " not found.")

    stop(t_err_msg)

  }

  t_cmd_string <- paste0(

    # Build Linux shell command string

    'head -c 500 ',

    t_file_name,

    '| grep -a -o  -E "temperature was .{0,5}"'

  )

  system(t_cmd_string, intern = TRUE)

}

This just gets the temperature rather than the whole header.

You could use an Hex viewer. I found HxD quite fast and usable. https://mh-nexus.de/en/hxd/

Hi David,

Apologies for this, I'll be releasing a fix shortly.

Peter Open Acoustic Devices

It worked beautifully! Many thanks Alex!

Answers below:

1. Yes these are first order Butterworth filters. There is quite a good online tool here - https://www-users.cs.york.ac.uk/~fisher/mkfilter/trad.html - that shows the frequency response of the filters that AudioMoth uses. The main benefit with bat recordings is the removal of low-frequency background sounds. If you aren't using the amplitude threshold recording then recording un-filtered and applying filters after data collection would allow high-order filters to be used.

2. Yes. A Butterworth filter at 1/4 of the sampling rate is simply averaging over neighbouring samples and this removes noise and aliasing.

As for the request:

A. Yes, the 1.4.0 firmware does this. It writes a human-readable CONFIG.TXT file when you switch to CUSTOM and just before the first recoding is made. All the file specific settings are also in the comment section of the WAV header (all apart from the schedule information).

B. Yes, we can strip that out into a script.

C. Yes, someone else raised the idea of 'chopping up' rather than 'expanding' the amplitude threshold files. This is definitely doable and we'll add that onto the next additions to the config app.

The decompress.js file is a node.js file that basically does exactly what you need already for the scriptable expansion. It exports a decompress(path) function. Pass it the path of the 'T' file and it will write the expanded file to the same destination.

Alex, Thanks for the quick response. The link to the filter design pages is very useful so will look at how this works some more.

I didn't realise you had already addressed the write out config idea, sorry for not checking first.

I've never looked at node.js before but the code looks easy to understand so I'll see what I can do to script it.

Finally the weather looks better this evening so I'll try for the back-back recordings.

Regards.

EAP

The paper is up now - https://github.com/OpenAcousticDevices/White-Papers

Thanks Alex,

that's very useful and I can immediately start to see some fantastically useful implications such as deployment times not being limited by data storage capacity or that lower storage capacity cards (which are cheaper) can be used to get the same deployment times or better (subject to batteries being up to it).

Please can you confirm that my understanding outlined below is correct for the amplitude threshold recording facility:

· The size of silent periods/gaps relates to the threshold value that is set.

· The threshold value that is set relates to KB and therefore milliseconds.

· Each 32KB segment (32000B) equates to 85 milliseconds (when using a 192 khz sample rate, would be more like 64 milliseconds if using 256Khz).

· So if an amplitude threshold of 512 is selected (and 192Khz sample rate) any gaps of 1.32 milliseconds (85 milliseconds/32768 x 512) or less with no data (depending on how low, band or high filters have been set) will be removed from the recordings. Is that correct or would it be gaps of this size or more that would be removed.

· The amplitude threshold will only work effectively if low, band or high filters have been set to reduce non target sound/background noise. Otherwise a gap will need to be present across all frequencies within the range of the microphone?

Hoping I have understood correctly.

Brian.

@Brian Armstrong Hi Brian, The amplitude threshold refers to the amplitude of the recorded signal and is applied to the actual samples collected by the AudioMoth within each 32KB buffer (32 * 1024 bytes). If there are one or more samples with amplitude greater than or equal to the threshold value within the buffer then that buffer is written to the SD card. If not, it is not written but a record of the fact that there is now a gap in the recording is maintained. The actual length of the buffer is only really relevant as this will be the minimum length of any noisy or quiet period, but both the noisy and quiet periods can be any multiple of this minimum buffer length. It is the minimum period over which a record or not record decision is made. The amplitude threshold will work independently of the filters. The filters just help to remove the background sound so that you only trigger on the sounds of interest. Alex

Hi Kari,

Which browser are you using to download? Could you try a different one and see if the problem persists? I've tested the download links on a variety of operating systems and browsers with no issue. Would be good to work out what's happening to you here.

Peter Open Acoustic Devices

I had the same problem with win10. The download creates a (name).part file during the download, but fails to complete the download. Maybe the closing bit missing? What I did is that I removed the extension ".part" from the name. The remaining files worked fine for installation. My browser is the latest firefox.

Mainly because it tends to be more flexible and works better in lots of settings. If you want to record for 1 hour and there are sixty trigger events in that hour, rather than having to sequentially open and look through sixty separate files, you can open one and see all the events together. You can then expand that file out to see the timings of all the individual events (down to sample level accuracy) as if you had made one continuous recording. The expanded version can always be regenerated so there is no need to keep that one. Another reason is that it typically takes 1-2 seconds to close and open a new file on the SD card and buffering that much sound at 384kHz isn't possible on AudioMoth. The standard triggering approach would leave some blind periods where you aren't actually capable of recording anything. For many applications this doesn't matter but for some you really want to know that you were actively capable of detecting an event for the entire period.

Since the recorded file has all the relative timings it's also possible to have the configuration app 'chop up' the recording, rather than 'expand it'. That way you get the individual recordings that you would have had from the triggering approach but without the blind periods between recordings. We haven't done that but it would be easy to add if there was demand for it. Setting the filter and the amplitude threshold is probably what you'd have to do for triggering anyway as this needs to be quite flexible to work in different settings (e.g. for triggering on bats, birds, speech or traffic say)

@Alex Rogers "Since the recorded file has all the relative timings it's also possible to have the configuration app 'chop up' the recording, rather than 'expand it'. That way you get the individual recordings that you would have had from the triggering approach but without the blind periods between recordings. We haven't done that but it would be easy to add if there was demand for it."

That would be FANTASTIC, as it would allow AM recordings to be used in the normal workflow by the main Bat ID software. Ability to have configurable "chop up" times, would be ideal - 15sec, 30sec, .. etc, to allow easier analysis of bat passes.