First installation of BirdNET-Pi

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.

epydemic hits 100,000 downloads

epydemic hits 100,000 downloads

Downloads of epydemic, my library for epidemic (and other) process simulation on networks (and hopefully other combinatorial structures soon…) recently passed 100,000.

That number comes from the project’s PePy page, which tracks downloads from the main PyPi page as used by pip. I can’t say whether or not that number is accurate. Quite honestly it’s at least 98,000 more than I ever expected, but 100,000 feels like something of a milestone to be pleased about.

epydemic came about because of a lack of standard tooling for doing epidemic simulation. This involves a lot of stochastic simulation, which is quite tricky code to write and to make efficient. Testing the system actually involved us thinking more deeply about the effectiveness of unit testing for stochastic code, which then led to a presentation at UK Systems in 2021 explaining the problems we’d had.

TIL: The loudest Lisp program in the world

TIL: The loudest Lisp program in the world

Today I learned about a program that generates the sounds that help people navigate as they exit long tunnels when an emergency such as a fire has destroyed the visibility.

The World’s Loudest Lisp Program to the Rescue

This describes the challenges of building a software system that has to work unmonitored once deployed, for years, as well as withstanding a fairly rugged environment where, for example, the installedc hardware will be periodically sprayed with a high-pressure hose as the walls get cleaned. Overall the system is soft real-time, but has to cope with component failure, network partitions, consensus, and all the usual distributed systems challenges, while be guaranteed to work when needed.

The developers built the system in Common Lisp, which wouldn’t be the normal go-to choice for an embedded system. But their argument was that they could better handle complex and changing requirements by retaining a high level of abstraction, and that development was overall far faster than using C. Modern Common Lisp compilers are so efficient that there’s no significant performance hit at deployment. They made use of complicated components like planners (for which Lisp is an ideal choice), and built a set of macros to wrap-up the handling of industrial control and robust communications.

It’s a great read.


Stephen Walker (2021)

The space race from the American perspective is well-known: this book presents the same race from the Soviet perspective.

The differences are profound, of course, mainly driven by the Soviet programme occurring in complete secrecy to duck the risks that failure would have on the programme’s image. The American programme by contrast was conducted in the open at least as far as the actual “shots” were concerned – and their public failures did indeed endanger their ability to continue, at least in part because neither public nor politicians understood the process of engineering or just how hard each shot was. The deep irony is that the Soviet successes appeared so sudden and dramatic they led directly to the deepening of the American programme and commitment or more money and effort than the Soviets seemed able to maintain to capitalise on their early lead.

There are plenty of revelations even for those with a detailed interest in space history. I remember hearing all through the 1970s that the Soviet spacecraft landed on land, but it turns out that in many cases the cosmonauts were bailing-out and parachuting to earth instead, with this being intensively covered-up even to the extent of falsifying reports to the international organisation responsible for certifying “firsts” in space.

While the achievements of both programmes were profound, they were perhaps doomed in the long term by a lack of vision for what they were actually for. The benefits of space technology are now obvious; those of exploration perhaps less so, although it doesn’t (in my opinion) require much suspension of disbelief to feel that science-driven activities lead almost inevitably to enormously valuable spin-offs. The fact that we can’t quantify these a priori shouldn’t (in my opinion, again) stop us keeping the faith in the value of experiments that advance our science and engineering in ways that wouldn’t otherwise happen.

5/5. Finished Sunday 21 April, 2024.

(Originally published on Goodreads.)