Simon Dobson (Posts about sensing)

Processing MicroMoth recordings offline

Simon Dobson — Mon, 10 Jun 2024 11:57:22 GMT

Processing MicroMoth recordings offline

The uMoth generates .wav files, uncompressed waveforms of what it records. These need to be processed to identify any bird calls within them.

This function is integrated in BirdNET-Pi, which does recording and classification, and provides a web GUI. With the uMoths we need to provide classification as part of a data processing pipeline. We can however make direct use of the classifier "brain" within BirdNET-PI, which is unsurprisingly called BirdNET-Analyzer.

Installation

I'm working on a 16-core Intel Core i7@3.8GHz running Arch Linux.

First we clone the BirdNET-Analyzer repo. This takes a long time as it includes the ML models, some of which are 40MB or more.

    git clone https://github.com/kahst/BirdNET-Analyzer.git
    cd BirdNET-Analyzer

The repo includes a Docker file that we can use to build the analyser in a container.

    docker build .

The container setup is quite basic and is probably intended for testing rather than production, but it gives a usable system that could then be embedded into something more usable. The core of the system is the analyze.py script.

Analysing some data (AKA identifying some birds!)

The container as defined looks into its /example directory for waveforms and analyses them, generating text file for each sample. The easiest way to get it to analyse captured data is to mount a data directory of files onto this mount point (thereby shadowing the example waveform provided).

There are various parameters that configure the classifier. I copied the defaults I was using with BirdNET-Pi, only accepting classifications at or above 0.7 confidence.

    docker run -v /var/run/media/sd80/DATA:/example birdnet-analyzer analyze.py --rtype=csv --min_conf=0.7 --sensitivity=1.25

This crunches through all the files (982 of them from my first run) and generates a CSV file for each. An example is:

Start (s)	End (s)	Scientific name	Common name	Confidence
6.0	9.0	Corvus monedula	Eurasian Jackdaw	0.9360
9.0	12.0	Corvus monedula	Eurasian Jackdaw	0.8472
12.0	15.0	Corvus monedula	Eurasian Jackdaw	0.8681
15.0	18.0	Corvus monedula	Eurasian Jackdaw	0.8677
24.0	27.0	Columba palumbus	Common Wood-Pigeon	0.9198
27.0	30.0	Columba palumbus	Common Wood-Pigeon	0.7716
45.0	48.0	Corvus monedula	Eurasian Jackdaw	0.8023
48.0	51.0	Corvus monedula	Eurasian Jackdaw	0.7696

Those are entirely credible identifications. The start- and end-point offsets allow rough location within the recording. (BirdNET segments the recordings into 3s chunks for analysis.)

This is clearly not as straightforward as BirdNET-Pi, nor as immediately satisfying. But it does scale to analysing lots of data (and could be made to do so even better, with a better front-end to the container), which is important for any large-scale deployment.

Deploying a MicroMoth

Simon Dobson — Mon, 10 Jun 2024 10:11:02 GMT

Deploying a MicroMoth

The MicroMoth (or uMoth) from is the same as their better-known AudioMoth recorder but with a significantly smaller footprint. It's just a traditional recorder or data-logger, with now on-board analysis and no wireless connectivity. I got hold of some to use in a larger project we're thinking about running, and they're not kidding about the "micro" part.

The uMoth uses the same software as the AudioMoth, and therefore the same configuration app available from the apps page – for 64-bit Linux in my case. It downloads as a .appimage file, which is simply a self-contained archive. It needed to be marked as executable, and then ran directly from a double-click. (The page suggests that there may be some extra steps for some Linux distros: there weren't for Arch.)

I then followed the configuration guide. The time is set automatically from the computer's clock when you configure the device.

For testing I chose two recording periods, 0400–0800 and 1400–1600.

As shown this will, with the default 48KHz sampling, generate about 2GB of data per day and use about 70mAh of energy. For my tests I just hung the device out of the window on a USB tether for power: it works fine drawing power from the USB rather than from the battery connector.

This turned out not to record anything, because the time is lost if the power is disconnected, even though the configuration is retained. (The manual does actually say this, with a suitably close reading. It could be clearer.) There's a smartphone app that can reset the time once the device is in the field and powered-up, though, by making an audio chime that encodes the current time and location in a way the board can understand. Flashing the device with the "Always require acoustic chime on switching to CUSTOM" makes it wait after power is applied until its time is set.

The red LED flashes when the device is recording. The green LED flashes when the device is waiting for a recording period to start. The red LED stays lit while the time is unset.

First installation of BirdNET-Pi

Simon Dobson — Sun, 19 May 2024 14:19:45 GMT

First installation of BirdNET-Pi

The BirdNET-Pi system aims to provide out-of-the-box bird identification. It's slightly more awkward than that, but still pretty straightforward to get up and running.

My first hardware plan was to use a Raspberry Pi Zero as the compute host with a Waveshare WM8960 HAT for the sound capture. It turns out that BirdNET needs a 64-bit platform – why I'm not sure – and the Pi Zero only runs 32-bit Linux. I therefore moved to a Raspberry Pi B that I had lying around, and put a 64-bit "lite" install on it to run headless.

I then basically just followed the installation guide. There was an issue with the installation script when cloning the GitHub repo: I suspect this was because of limited memory on the Pi. I downloaded manually, and manually ran the rest of the install script, which did a lot of setup of services and a PHP web server.

I compiled the drivers for the HAT, which worked fine. The new sound card is recognised but is not the system default.

The installed components seem to include:

icecast2, a streaming server, used to replay recordings
caddy web server
PHP for serving the web pages
arecord to actually record audio
ffmpeg to extract waveforms
sqlite for the database
the actual machine learning model used for recognition

The recognition models are built with TensorFlow. This is a great example of how the standard Linux tools and services can be combined to get a scientific-grade sensor platform. (Caddy doesn't seem to be running over TLS by default, which would be an issue outside a firewall.)

Since the sound card isn't the default, the easiest way to get the system listening to the right mics is to change the device in the "advanced settings" panel: in my case I changed from "default" to "hw:2,0", reflecting the output of arecord -l that shows the sound card devices.

I then deployed the Pi out of the kitchen window.

To start with it wasn't hearing anything, which I think may be because of the waterfall in the courtyard: turning this off made things much more effective:

That's an appropriate set of birds being seen – and we hardly ever see magpies, but know they're around. There's actually quite a lot of background noise even in such a quiet village, but the bird calls do stand out.

I can't see any reason for the manual installation on bare metal: as far as I can see everything could be containerised, which would make deployment and management a lot easier.

The parts arrive

Simon Dobson — Fri, 21 Jun 2013 09:00:32 GMT

The parts have arrived for the ditch project.

The first tranche of hardware came (in a small box) today:

There are parts here for four sensor packages and a base station. The sensor nodes have an Arduino, a 2mW XBee radio, and a digital temperature sensor. The base station has an XBee and a wired ethernet for connecting up to the internet. There are also some prototyping shields to simplify integration, a wall wart power supply for the base station, and some other goodies to support some other development.

Sensor mote initial parts list

Simon Dobson — Thu, 20 Jun 2013 13:05:29 GMT

The initial design for a sensor mote puts three temperature sensors together with an Arduino and short-range radio module. The following is the parts list for a single sensor mote:

Arduino Uno -- £18.50
Arduino XBee shield -- £12.10
Arduino Series 2 2mW XBee radio module -- £17.50
Arduino prototype shield -- £10.40
Mini-breadboard -- £2.00
3 x DS18B20 one-wire digital temperature sensor -- £11.70
Battery holder -- £1.20
Enclosure (waterproof, resealable food box) -- £3.50

A total of £76.90 (+ VAT) per sensor, not including assorted wires and resistors. [UPDATED 11Jul2013: added cost of enclosure]

The ditch project: a motivation

Simon Dobson — Wed, 19 Jun 2013 20:02:20 GMT

Citizen Sensing's first project is to perform environmental monitoring on a small scale with minimally-specification hardware.

We have three sets of goals from this project. Firstly, we want a realistic scientific project that's simple enough to accomplish over a summer. Secondly, we want to gain some experience with technologies in the field, what works and what doesn't at this level of sophistication. Finally, we want to develop an initial software platform that can support further experimentation. To deal with these in order:

The science will be very simple. Some areas have climates that vary over very short distances, and these variations can affect the flora and fauna that live there. In particular, areas like depressions and ditches often have different temperature profiles than the surrounding areas, with less variation in temperature, that may suit some species. While this is clear in general, the specifics often aren't well-understood, so it's a worthwhile scientific exercise to measure temperature variation around a small area. Specifically, we'll seek to measure temperature variation around a ditch we have access to, in County Sligo in the West of Ireland.

The technology will be off-the-shelf hardware, using Arduinos for processing and XBee radios for communications. These are extremely cheap commodity items that haven't really been used for experimental environmental science, and it's by no means clear that they're appropriate for building a long-lived, robust sensor network.

The main software challenges include working the hardware and -- more significantly -- managing the very limited power budget one gets with standard batteries and hardware. In building the software, we're aiming for a re-usable platform that can be packaged in a form so that the experiment can be reproduced or used as the basis or other experiments by other groups of scientists.

Is this a worthwhile project? From a scientific point of view its clearly questionable, but that's not the point: this sort of experiment is representative of a wide range of environmental sensing, both citizen and professional, so making it work opens the door to a wider spectrum of investigations without getting bogged-down initially in the details of a scientific challenge when the computing is so new and uncertain.

The blog for the project will let you follow all the gory details.