It's over a year since Andy posted: "We are still in the process of restructuring the sound triggering functionality for the current AudioMoth hardware" (Jan 15, 2018).
Lack of triggering functionality remains the major disadvantage of the AudioMoth - is there likely to be a solution for this issue?
Hi, I think this would probably be easiest to address with a custom version of firmware so that the exact use case can be addressed and we can run some experiments. For 48kHz sampling we can slow down the processor which reduces energy consumption. We've also been experimenting with a compression approach that removes 1024 sample segments from the recording if the maximum amplitude over that region is less than a preset threshold (or possible one that is calculated over time in order to give resistance to changing background levels). The length of the gaps is written into the WAV file so that the recording can be expanded out to the correct length after collection. This has the advantage that you are listening all the time and always capture the sound that actually triggered the device. By writing a lot less raw audio to the SD card you also dramatically reduce the energy consumption and the size of the SD card that you require. We are also experimenting with a variant of the hardware which is super small and intended to run from small lithium-ion batteries. It will be electrically identical to the current AudioMoth 1.1 hardware so should be interchangeable in applications. Alex