Wildlife monitoring equipment has always been an ad-hoc, niche industry where scientists often have to create their own devices from scratch or modify existing consumer devices to do what they need. AudioMoth is a scratch-built wildlife audio monitoring device developed by scientists at the University of Southampton and Oxford University to monitor audio sounds unattended in the wild.
The device is already in production, available via Groupgets, and in the hands of wildlife researchers, ecologists, and conservation organizations that will be putting it to use to monitor the sonic landscape in areas around them. It will be put to use to track hard-to-detect wildlife as well as poachers that could be illegally logging or killing off animals.
The device was designed to be a low cost, high performance recording device that had features needed for wildlife researchers and could be deployed in the wild. The primary concerns were affordability, power consumption, and audio performance so they could deploy it in the wild and record animal calls or human activity.
The Innards
AudioMoth works by having a circuit that samples audio at up to 384k samples per second. Sampling at these high frequencies allows them to capture sounds beyond the range of human hearing like bats who use ultrasonic frequencies for location and to find prey. The system is also low power which means they can deploy it in the field for weeks at a time to record sounds of interest. As far as I know, there is nothing similar to this for wildlife researchers which means that it could be used to document soundscapes that were never captured before.
Power consumption is probably one of the biggest features of this device. Any recorder can be used to capture sound, but there probably aren’t many that could survive for weeks in the wild while continuously recording. How this power consumption is achieved is quite interesting.
The system uses the EFM32 Gecko microcontroller from Silicon Labs. It’s not as popular as the standard ARM Cortex M3 or M4 microcontrollers from NXP and ST Micro, but it has some unique features. One of them is that it’s possible to set up asynchronous events (Peripheral Reflex System or PRS on the EFM32) that can occur without microcontroller intervention.
What this means is that you can keep the MCU asleep while things happen in the background. In this case, they keep a timer running in the background and when it goes off, it triggers the analog to digital converter (ADC) to capture an audio sample. When the capture is finished, the PRS system triggers the direct memory access (DMA) controller to send the audio sample data directly to the SRAM. This all happens while the controller is asleep in its low power mode. As per the stock firmware on github, the MCU wakes up once per second, probably to write all the data in the SRAM to the SD card.
Keeping the system asleep isn’t the only low power technique happening here though. Along with this, you need to use a variety of low power components to reduce the power draw and prolong the life of the batteries.
For power management, they are using the LT1761 from Linear Technologies, a micro-power voltage regulator with very low quiescent (idle) current. Quiescent current is commonly called Iq and determines how much current a device draws even when nothing else is drawing current. The sum of all the quiescent currents in the system will dictate the limiting factor on power consumption. The lower the total Iq, the better. So much for smart devices, ha ha ha (ba-dum-tssss).
They also have quite a large 4Mbit or 512 kB SRAM that is used to buffer audio samples while the device is asleep. SRAM is actually a bit of an expensive choice in terms of RAM, especially if you need large amounts. The cheaper option for bulk RAM storage would be SDRAM but it’s a leaky technology which means that it consumes a lot of power for an energy constrained device like this. Because of charge leakage, SDRAM needs to constantly be refreshed so in this case, going with SRAM would be the better choice for low power operation, even at extra cost.
For bulk storage, there is an SD card connector on the AudioMoth that can house micro SD cards. These days, SD cards can range up to 512 GB which is an insane amount of bulk storage. If the audio samples are managed in even a slightly efficient way, you can keep the system out in the field for months without running out of memory. One thing to note is you have to be particular in the types of SD cards you use. Many don’t implement power saving features as they should. We’ve had our best results using SanDisk SD cards. Also there is a note on the speed class of the SD card for the AudioMoth here.
The audio interface is the heart of the system and comprises an analog MEMS microphone. MEMS stands for micro-electronic mechanical system) and is pretty much what it sounds like, a very tiny mechanical system. Big microphones like condenser microphones usually have a large flat plate that vibrates according to the sound waves that hit it. These microphones usually need a 48V bias current to run and are very power hungry even though they sound good. MEMS microphones use a micro-machined membrane that can run on lower voltages. They typically offer high signal to noise ratios, low power consumption, good sensitivity, and come in small packages. MEMS microphone technology went through a boom since they were mainly developed for cellular phone applications. Now they are widely available and, due to economies of scale, very cheap.
Another interesting feature of the EFM32 microcontroller is that it has built-in op amps that can be chained together. The AudioMoth takes advantage of these components to create a pre-amp that the analog MEMS microphone feeds into. Normally you would need an external pre-amp to condition the signal to go into an analog-to-digital converter but in this case, it’s taken care of internally. The op-amps set the gain and offset of the analog signal so it can be read accurately by the ADC.
The next link in the chain is the analog-to-digital converter (ADC). Once the audio signal gets to this point, the ADC gets triggered at some interval to provide a specific audio sampling frequency. For human range hearing, this is typically 44.1 kHz or 44,100 samples per second. The built-in ADC in the EFM32 is 12-bits wide which is quite decent for audio samples. Audio sampling typically starts at 8-bits per channel and tops out at 16 bits per channel in high fidelity systems (although it can go up to 24-bits in pro gear). Designing for higher than 12-bits of resolution would take a lot of special consideration because as you go to higher resolution, you start having to battle ambient signal noise. 12-bits for an audio signal is not so difficult in terms of layout, but a 16-bit audio system or higher would require extremely special care.
The system tops out at 384 kilosamples per second. This would be useful for capturing ultrasonic events out of the realm of human hearing such as bats and their ultrasonic echolocation. The downside of running the system at such a high sample rate is that total data throughput runs at over 4 Mbps. This is pretty high in terms of memory consumption and you’d fill both your SRAM and SD card fairly quickly. In cases like this, where high sampling rates are used, care would need to be taken with the memory subsystem to capture and store data efficiently.
Once the data is past the ADC, then it’s really application specific. From this point, the developers assume that whoever uses the board will implement their own functions. They leave some empty interrupt calls for people to fill in for themselves.
Conclusion
Overall, the design is very clever and they make extremely good use of some of the more unique features of the Silicon Labs EFM32 Gecko microcontroller to achieve a low power system. What I really liked about it is they fulfilled a need in an extremely narrow niche, wildlife and environmental researchers focusing on capturing soundscapes. At the price point they’re offering it at, it’s a huge deal for anyone involved in this field.
Improvements?
I really like the design and they used many clever techniques to optimize it specifically for what it was designed for. I would like to see some additional features though:
- Enclosure – I would target it to an enclosure, likely IP65 or higher so that it would be industrial strength waterproof and dustproof for harsh conditions. This would also mean the microphone would need to be mounted externally or have a small breach in the enclosure for the microphone to poke out of. An enclosure goes a long way in improving device robustness, especially for environmental applications.
- Solar charging – I think the system might benefit from solar charging capability. According to the FAQ, the daily power consumption is approximately 100 mAh. This means that a typical 2000 mAh lithium battery would drain in less than 20 days. Having a solar charging circuit would extend the field life in some applications (where it’s exposed to sunlight).
- Arduino or Micropython version – In a lot of cases, writing bare-metal C for an ARM processor is daunting to people that aren’t computer science majors older than 40. Having a version that runs on Arduino, Micropython, or even ARM mBED, even if it means giving up some of the low power features, would probably increase the user base. Right now, the users are likely research teams and organizations that have access to an experienced embedded programmer that can slot into the API and customize libraries and functions as needed.
- MP3 Encoder – An optional MP3 encoder would be an interesting addition. It would involve more software but if you can deal with lossy encoding, MP3 compression can often reduce the size by a factor of 10x. That’s a huge amount and if the battery life is optimized, it would be possible to collect months of audio data on today’s large SD cards.
Overall, I really like the goal of the project, the fact that it’s open source, and that it addresses a fascinating, narrow, unserved niche. Overall, I’m interested to see how this project progresses and in the meantime, I’m already considering checking out the EFM32 for a test project to see how useful the PRS system is in the developmental infrastructure context we work in at FreakLabs and agriculture context we work in at Hackerfarm.