Getting to an Inexpensive Audio Datalogger

Well, I spent my Saturday morning programming a C# application for Windows Mobile 5 to periodically record audio.

I was aiming to set up a data logger using the Raspberry Pi board I’ve got, but I’ve run into enough problems that I decided to look at another approach.

The idea is to log acoustic data underwater to get snapping shrimp snaps. Snapping shrimp are small crustacean predators who use a specialized claw to generate cavitation events that stun or kill their prey. Cavitation events are loud, and snapping shrimp populations are large, so a major component of the acoustic background in tropical to semi-tropical waters where there is structure is snapping shrimp snaps. These various elements come together to make snapping shrimp an excellent indicator species. The acoustic record can be used as an indicator of population health for snapping shrimp, and since snapping shrimp are metazoan predators, they indicate the health of the ecosystem.

The state of Florida has a Harmful Algal Bloom (HAB) program where monitoring stations are scattered around places. The stations have power, some have internet, and there’s space for more instruments to be loaded aboard. The regular schedule of sampling of other instruments is four times an hour. So I’m looking to sample one minute of acoustic data on each quarter hour, so my data can be correlated with the data generated by the other instruments.

The Raspberry Pi looked pretty promising as a data logging platform. It comes with an SD card slot, has an Ethernet port, and allows expansion via USB. There are three things that are holding me back on that: stable power, USB audio compatibility, and time synchronization. Getting the RasPi to power on from a cold start is a piece of cake. Getting it to reboot with “sudo shutdown -r now” is not reliable. This is likely a power interaction between my power source(s) (I’ve tried three so far) and the USB hub(s) (I’ve tried two so far). The recommended low-cost USB audio interface for Linux is a Behringer UCA202. ALSA on the RasPi, though, doesn’t think it has a capture device. The RasPi doesn’t have an RTC. This isn’t a problem with an Ethernet connection to the internet, but it is a problem if there is no connection when the RasPi boots. I’ve tried setting up GPSD with NTP to fill in when there is no network connection, but with negative results so far.

That brings me to my alternative plan. Back in 2005, Diane and I had to hurriedly design an autonomous acoustic recording system with COTS parts in order to deploy in three weeks for a field season in Wyoming. We settled on using Pocket PC devices with Core Audio’s PDAudio sound cards and A/D devices. I rigged regulated power supplies that ran off motorcycle batteries so that each unit only had to be serviced every couple of days to swap batteries and memory cards.

Since I’ve gotten my Android phone, I haven’t been using my Dell Axim X50v PDA much. I’ve done ad hoc recordings with the X50v before dropping a hydrophone over a seawall or overpass, and it’s done OK. So I started looking at audio programming for Windows Mobile devices. It was a bit tougher than it strictly needed to be. The declining market share for Windows CE/Pocket PC/Windows Mobile means that application development goes through Visual Studio 2008, not the latest development tools. (I did install SharpDevelop, but dropped that for VS2008). Audio support for Windows Mobile looks pretty minimal. There’s an interface based on the Platform Invoke Library (PIL) provided by Microsoft, and there’s the OpenNETCF library that wraps the PIL. I tried OpenNETCF because it looked simpler to implement, but I ended up with memory leaks. Using PIL directly gave me success this morning, and now I’m just letting the application record one minute of audio every five minutes as a test. The system memory report under Settings is showing stable usage of memory so far. I’m aiming to deploy the system where it will only be serviced every two weeks, so I really need to watch out for long-term problems. So far, though, it looks like I should be able to finish up with power supply issues and the acoustic gear side of things and get it installed by the time the next HAB station gets deployed. And it fits on the budget I’ve got, which is pretty close to nothing at all.

—-

I spoke a little too soon. While the periodic recording bit seems stable and I appear to have quashed memory leaks, I think I’ve got a hardware issue. I had listened to a couple of recordings that actually picked up the signal I was providing on line-in. I checked some more, and found that at some point the X50v went back to recording from its built-in microphone. That, of course, does me no good. I have tried two different cables with the same result. Usually, switching with a plug is simply a matter of physical displacement; if the plug is in, the alternative input makes no connection to the system. I’m not sure how it goes with the X50v, but I’ll probably have to disassemble it to find out.