Any Progress on Sound Triggering?

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

Thanks Alex, my use is for audible sounds rather than bat detection. Will the release work with audible sounds as well? What we're considering is a collar-mounted audiomoth that can record chewing, allowing us in turn to measure the timing and amount of feeding. We've done this successfully before and transmitted the signal to an analogue recorder in real time (yes, this was a while ago) with not great results. Recording on board with improved microphones will be a great advance, with battery capacity being our ultimate limitation. Any way we can extend the battery lifetime or reduce battery weight will be a big win for us. Will the new configured binary files also rely on a different wake-on-sound microphone or will they work with the exisiting audio moth microphone? And how quickly can the micro controller wake and record audio?

We'll try to get this out in the next couple of months for bat detection. We've been trying to figure out how to do this without having to support lots of different versions of firmware and configuration apps which we don't have the capacity to do. We've now figured out a lightweight way to do this through an 'AudioMoth Labs' feature on the website which will provide configured binary files of the application, all of which will use the Time App to set the time before deployment.

It will be firmware release so is independent of the GroupGets builds and will work on all the versions of AudioMoth in circulation. The wake-on-sound feature of the Vesper microphone makes a big difference to energy consumption if you use it to wake up the micro-controller, as well as the microphone, when you detect a sufficiently loud signal. That's the real use case - the micro-controller enables the microphone and then goes to sleep, using effectively zero energy, and then wakes up to record something to SD card when something is detected. Writing to SD card takes the most energy, so you can save a lot by using the micro controller to decide if there was a sound and only writing the file is there was. You save a lot more by getting the microphone to make this decision whilst the microcontroller is asleep.

Hi, I don't want to sound too impatient, but is there a rough estimate as to whether and when this is still likely to happen? Presumably we can be confident that this won't be implemented in the round 7 GroupGets release, but is it likely to make the next release? Once implemented, will it be available sooner from LabMaker?

On a related and probably naive note, what would be the consequences of using a Vesper vm1010 wake-on-sound MEMS microphone with continuous cording on the current AudioMoth release? I'm imagining there would be no savings on power usage but would having the microphone asleep result in memory savings? Or would a null audio signal be recorded? Is that about right?

Hi, Yes, it is coming. Basically waiting for Peter to finish writing his thesis so that he has time to release the new versions of code. We have a trial deployment at the moment. I appreciate its annoying having to wait. Alex