Monday 12th March was something of a landmark for us: Simon finally got to install one of our Audio Capture Devices (ACDs) on a tree in the Meadows! He is using a clever combination of bungee cords and bike cables to make sure that they are firmly attached.
A few teething issues in getting the ACDs to talk the server are being ironed out, and we should be able to report back soon on what data is being collected.
In preparation for this public launch, Silje toured notice boards around the Meadows to put up information leaflets. And for those who want to know more, we’ve added a QR code to the poster that points to our Privacy Notice.
So finally, we have been able to bring the full CitySounds Data Collector architecture online, and are now receiving encrypted audio data from our field test device, which is placed in a University private garden via our exernal WiFi AP mounted on the 5th floor of the Main Library.
The image above shows the 10-second audio samples (transferred via scp and separately encrypted with GnuPG) flowing through onto the CitySounds server from one of our Audio Capture Devices (ACDs). Never has a directory file listing looked so pretty!
Our Raspberry Pi based ACDs are also now fully time-synchronised through our local NTP server to ensure they work collectively and accurately to cover off each 60-second block of time. Once all six ACDs are deployed, they will each record a 10-second slice in sequence.
We are now on track to deploy to the trees in the Meadows in Edinburgh early next week: this will be a major accomplishment, especially given the additional extreme weather and strike issues we have been having to navigate the last couple of weeks.
I am in the thick of developing the sound installation for this project which will reveal some of the concepts behind our work and show some of the sounds that will be captured by the Simon Chapple’s sensor network. I’ll explain more about that in another post soon. Meanwhile, I’m taking a break from thinking about gel loudspeakers, compass and heading settings on mobile phones in order to say a little about my experience working with Simon’s Rasberry Pi, wireless, 192kHz audio beacon prototype earlier this year.
Simon lent me his prototype in order for me to hear what’s going on in my garden in late January and to run some noise profiling tests. I was keen to see if the small mammals that must live in the garden are interested and active around our compost heap. I dutifully positioned the sensor box where I hoped I’d hear mice and other mammals fighting over leftover potato peelings but sadly — as far as I can tell at least — nothing of the sort: no fights or mating rituals at this time of year. The absence of activity is useful, since it suggests that there has been plentiful food for small mammals to find earlier in the year/day and they’re not risking the wind, rain, snow and something new in the garden to get a late night snack. However, a largely quiet night means that the few moments of sonic event are all the more interesting and easy to spot.
A word on the tools I’m using
I’ve been using SoX to generate spectrograms of the 10-second audio clips collected. It’s a good way to quickly inspect if there is something of interest to listen to. With over 9 hours of material though, it’s not interesting to listen to the whole night again. Instead, I first joined all of the files together using a single command line from SoX in the terminal window on OS X:
sox *.wav joined.wav
I then generated a spectrogram of that very long .wav file. However, the resolution of a 9 hour file needs to be massive to give any interesting detail. Instead, I decided to group the files into blocks of an hour and then rendered a 2500 pixel spectrogram of each 10-second burst. It’s very quick to then scroll down through the images until something interesting appears. Here’s the .sh script I used:
### Generate for WAV
for file in *.wav; do
sox "$file" -n spectrogram -t "$title_in_pic" -o "$outfile" -x 2500
From the rendered spectrograms, I can quickly see that there were some interesting things happening at a few points in the night and can zoom in further. For example this moment at 1:43 am looks interesting:
It sounds like this:
I suspect that this is a mouse, cat or rat. Anyone reading this got a suggestion as to what it might be?
As the night drew on, the expected happened and birds began to appear — the first really obvious call was collected at 6:23 am. It looks like this:
And it sounds like this:
If you’re able to hear this audio clip, then you’ll be aware of the noise that is encoded into the file. One of our challenges going forwards is how to reduce and remove this. I’ve tried noise profiling and attempted to reduce the noise from the spectra, but this has affected the sounds we want to hear and interpret. Bascially by removing the noise, you also remove parts of the sound that are useful. I’m reflecting on this and think that there are ways to improve how electricity is distributed to the Rasberry Pi in Simon’s box from the battery and whether we need some USB cables with capacitors built in to stop the noise. However, noise reduction may not be as important to others as it is to me. My speciality is sound itself, in particular, how things sound, I want to get rid of as much unnecessary noise as possible so that when I’m noisy, it’s intentional. However, for an IoT project, the listener isn’t going to be a human but a computer. Computers will analyse the files, computers will detect if something interesting is happening and computers will attempt to work out what that interesting thing is based on things it’s been told to look for. It’s highly likely that the noise, which very quickly makes these sounds seem irritating and hard to engage with for a human, may well be perfectly fine for a computer to deal with. Let’s see.
We have prototyped a bio-acoustics listening device based on the Raspberry Pi Zero W and Dodotronic Ultramic. We are about to start 24hr continuous run testing in cold weather in two test sites. So far, the power consumption is pretty much as predicted considering cold weather.
A battery that delivers 30,000mAh should give 7 days continuous operation before needing to be recharged, and with a number of power saving options employed on the Pi, the initial tests have certainly borne this out. The cold weather (we have had several days of sub-zero temperatures and snow/ice) has much reduced the battery capacity, which is not surprising given the characteristics of Lithium-Polymer batteries.
Separately, we have now configured a Libelium Waspmote-based temperature, pressure, humidity sensing device to work within our existing LoRaWAN IoT infrastructure.