An ESP32-based bird sound recorder

There's been quite a lot of interest recently on the subject of AI bird sound recognition. It's been used in various nature reserves around the country and featured on BBC Springwatch in 2024 where they used AI identification for analysing recordings made at RSPB Arne for monitoring purposes.

I have a friend and old work colleague who is an inveterate tinkerer, and who introduced me to BirdNET-Pi, which is based on a Raspberry-Pi and uses BirdNET to analyse the sounds. The BirdNET-Pi device is cool in that it uses WiFi to communicate in real time the birds it's detecting, so you can put it in your garden and see what it's hearing from the comfort of your warm house (see also BirdWeather), but this is also a drawback if it's a remote setup you want. There are commercial bird sound recorders that can be deployed remotely and their recordings analysed back at base; this is what was used at RSPB Arne. These recorders start at £160, and very much upwards. I thought I'd have a go at making my own, partly to save money and partly because it would be a challenge, and hopefully fun.

I've experimented with the cheap ESP32 microprocessor before, adding one to a humane mousetrap I'd made (thus creating possibly the world's first "mouse e-trap"!) which simply sends me an email to alert me to the fact there was a mouse in it - so that it didn't become an inhumane trap. The ESP32 is programmable via the readily available Arduino development framework. I use this on a Linux Mint system.

These are the main components of the recorder:

ESP32-WROOM-32 surface mounted module board

This is the ESP32 microprocessor mounted on a board with pins to allow connection to other components via breadboard or PCB/stripboard.

INMP441 I2S miniature microphone

An I2S MEMS (Micro Electro-Mechanical System) microphone. I2S is a standard communication protocol that is supported by the microprocessor. Another commonly available microphone, the MSM261S4030HO, can alternatively be used as it appears compatible.

DS3231 RTC module

Although the ESP32 has an internal clock, it gets reset when power is removed. The RTC (real time clock) module has a rechargeable battery that maintains the time, similar to (possibly even the same as) the component in your computers and other household devices that keeps their clocks correct. The recorder needs to be aware of the time so the sound files can be correctly time stamped.

Micro SD card module

Sound files are written to a micro SD card. The ESP32 program produces 16bit WAV data, at various sampling rates.

In the image below, from left to right: ESP32, DS3231 RTC, MSM261S4030HO microphone, SD card module.

The main components

This is the prototype put together on breadboard, using the MSM261S4030HO microphone:

and V1 on stripboard using the INMP441 microphone:

Enclosures

In both cases I used a food storage container as a cheap solution. They appear to have a sufficiently good seal to keep out the weather. The V1 box has survived a week in a cold and wet wood without any obvious wet inside. The microphone inevitably needs a small hole to let the sound in, and I tried to prevent any rain entering by fixing a small "ledge" above it.

Update: I tested putting a membrane (piece of sellotape) across the hole to keep out the weather, and it didn't seem to affect the sound

Power

The ESP32 can be powered from anything between 3.7V to 12V via its VIN pin, and the rest of the circuit powered from its 3V3 output pin. For the breadboard prototype I used a 600mAh 9V PP3 rechargeable battery which gave about 200 minutes recording time. The stripboard version (same circuit, same power consumption) uses a rechargeable Li-Ion battery. The 3500mAh one shown has powered it for 700 minutes recording time and the battery was not exhausted (although probably not far off). I have a 9900mHa one on order which should last proportionally longer. More on this later.

Programming

The recorder is centred around the microprocessor.  The essential part of the programming is taking data bits from the microphone interface and writing them to the SD card in WAV format. Surrounding this is a bunch of support functionality:

• a CONFIG file on the SD card which is is read to allow various parameters to be specified
• connection to the internet via WiFi if necessary to get the correct time and update the RTC module.
  
• logging to a log file on the SD card
• configurable recording time and between-recording sleep time

Between recordings the ESP32 enters deep sleep mode, which uses little power.

The microphone challenge

The biggest challenge was processing the data from the I2S mic correctly. As you'd expect, most of the how-do-you-do-that? came from finding examples on the Internet, and it turned out that none of the examples I could find appeared to be doing it correctly, as I eventually found out.

The I2S interface for a microphone can be configured to deliver data at a particular sample rate (e.g. 44kHz) and with a specified sample width (e.g. 32 bits). The INMP441 however delivers 24 bits of data in the high order bits of a 32 bit sample and this is fixed, so attempts to configure the interface to deliver something different are likely to lead to the wrong processing. My code shifts the sampled bits to produce a real 32 bit value, and then down-samples it to 16 bits. It samples at a rate of 24kHz, which gives a frequency range up to 12kHz (sample rate/2), sufficient to capture all bird sounds I've seen, and the sample size and rate I consider to be a reasonable compromise between quality and file size. A 2 minute recording produces a 5.8MB file (but see later).

As the sample rate is not hard-wired, it can be experimented with.  A higher rate will give a higher frequency cut-off, but at the expense of file size and possible dropouts if it's pushing the processor too hard.

More on batteries

I found that as the battery runs down, the recordings get shorter. I assume that (for a 3.7V battery) the voltage drops below the ESP32 threshold and somehow the recording stops. This isn't sufficient to power off the processor, as it goes to sleep after recording as programmed. I'm guessing that during sleep, the battery picks up again for the next recording, and this repeats until the battery dies completely.

Also, these later recordings also get noisier, fluttering and rhythmic "crackling". Again, I assume this is a result of insufficient voltage from the dying battery. I'm currently experimenting with increasing the voltage, through using 2 x 3.7V Li-ion batteries in series, or 2 x 9V PP3 batteries in parallel.

Battery life

Tests on battery life has so far shown:

Test with 3300mAh Li-ion battery until flat: 38 x 28 mins (with 2 mins sleep in between) = 1064 mins  17.5 hrs total recording, although last 25% poor quality probably caused by low voltage

Test with 2 x 600mAh rechargeable PP3 batteries until flat: 24 x 28 mins (with 2 mins sleep in between) = 670 mins  11 hrs total recording. All recordings good until end (which tends to confirm the suspicion that low voltage is causing the problem with the 3.7V Li-ion)

More on recording frequency

I started by using BirdNET-Analyzer to process the recordings. Then I discovered Chirpity, a tool designed to make the processing of large number of sound files easier. It uses BirdNET-Analyzer to do the analysis, and shows the detections found in a very easy-to-use form, as well as display a spectrogram of the sound. A really good program with lots of functionality.

BirdNET-Analyzer (according to Matt, the Chirpity author) works on files recorded at 48kHz, and will automatically upsample lower frequency recordings to this before analysis. Ideally, therefore, recordings should be at this sample rate. Chirpity does this resampling if necessary before feeding the files to BirdNET so BirdNET doesn't have to. But this does lead to differences, as Chirpity and BirdNET use different methods to do the resampling, Chirpity seeming to do better a better job (it uses ffmpeg, a tried and tested tool for audio file processing).

(BTW I need to be more careful about differentiating sample rate in ksps, and frequency, in kHz. The maximum frequency in the recording is half the sample rate i.e. 32ksps sample rate gives a max frequency of 15kHz.)

The bottom line for me it that if I'm going to use BirdNET directly, I should use 48kHz recordings (or upsample to this myself with ffmpeg). For lower sample rates, use Chirpity. However, given the functionality in Chirpity I don't see me not using it all the time. 

Until recently I'd been reluctant to believe identification was any better with sample rates greater than the 24ksps I've chosen, but discussions on the Chirpity discussion group has persuaded me that 32ksps would be better. This is because BirdNET uses up to 15kHz in its analysis (anything higher is thrown away).

Configuration

Recording is controlled by these configuration values in the CONFIG file:

// WiFi values for getting NTP time
// Don't specify if WiFi is not to be used
//SSID=Home;
//PASSWORD=xxxxxxxx;
//GMTOFFSET=0;

// we can save a bit of power by turning off the LEDs
//LEDS=0;

SAMPLE_RATE_KHZ=48; // 24, 32, 40 or 48
ATTENUATION_FACTOR=4; // turn down the gain

// Recording control for deployment
INITIAL_DELAY=90; // 1.5 minute in secs
RECORD_TIME=300;  // 5 minutes in secs
RECORD_WAIT=1500; // 25 minutes in secs

Wi-fi is only used for setting the real-time clock. If these values are specified the current date/time will be obtained from the Internet and set in the DS3231. As the DS3231 has its own rechargeable battery this should rarely need to be done, changing to and from daylight saving time would be the main reason under normal circumstances.

The INITIAL_DELAY is to give you time to get the recorder into position before it starts.

The other values are pretty self-explanatory.

Log file

 A sample log file:

2025/2/25 16:41:35 ===================================================
2025/2/25 16:41:35 Starting...
2025/2/25 16:41:35 SAMPLE_RATE_KHZ=48
2025/2/25 16:41:35 ATTENUATION_FACTOR=4
2025/2/25 16:41:35 INITIAL_DELAY=90
2025/2/25 16:41:35 RECORD_TIME=300
2025/2/25 16:41:35 RECORD_WAIT=1500
2025/2/25 16:41:35 Setting ESP32 clock from RTC: Tue Feb 25 16:41:35 2025
2025/2/25 16:41:35 Initial delay start
2025/2/25 16:43:5 Initial delay end
2025/2/25 16:43:6 Recording to file /13364305.wav
2025/2/25 16:48:6 Recording ended
2025/2/25 16:48:6 Temperature is 18.3C
2025/2/25 16:48:7 Going to sleep...
2025/2/25 17:12:16 ===================================================
2025/2/25 17:12:16 Starting...
2025/2/25 17:12:16 Recording to file /13371216.wav
2025/2/25 17:17:17 Recording ended
2025/2/25 17:17:17 Temperature is 10.3C
2025/2/25 17:17:18 Going to sleep...
2025/2/25 17:41:42 ===================================================
2025/2/25 17:41:42 Starting...
2025/2/25 17:41:43 Recording to file /13374143.wav
2025/2/25 17:46:43 Recording ended
2025/2/25 17:46:43 Temperature is 8.8C
2025/2/25 17:46:44 Going to sleep...
2025/2/25 18:11:8 ===================================================

...

The DS3231 module contains a temperature sensor, so why not use it?

File names

The SD card file system only supports 8.3 file names. I wanted the file names to be derived visibly from date and time, but the short file name makes this virtually impossible. The unique, ascending names that are used are created from the date and time but in a non-obvious way. When I upload the files to my computer I use a simple command to rename the files, using the file creation dates.

And next...

I still consider this to be work in progress. Perhaps at some stage I will put details on GitHub. Meanwhile if you would like more details, contact me via email.

Tracking comet C/2022 E3 ZTF

On 5 Feb 2023 I tested the tracker on the "green comet" aka C/2022 E3 ZTF. 

5 x 60 sec exposures, "fog-reduced" using GIMP levels adjust tool. Because the comet itself is largely fog, this does have the downside of diminishing the comet a bit. Swings and roundabouts I guess.

I'd not realized just how much the comet would move in the 22 minutes I was capturing the images, so I though it illustrative to combine them into a animated gif. I had to align the star field manually, so it jumps slightly between frames, but overall I was reasonably pleased with the result.

My notes from the night:

Green comet C/2022 E3 (ZTF) travelling through the constellation of Auriga for 22 minutes on 5 Feb 2023 between 22:07 and 22:30. A sequence of 10 x 60sec images. Camera Canon 5D3 with 200mm lens on home-made astro-tracker.

Bright star in the upper left is Capella, 1 deg 38 min distant. Vertically above the comet and 0 deg 14 min distant is HIP 24109, a mag 5.65 star. The comet is travelling through a triangle of mag 11 stars and moved approx. 7 arc mins during the 22 minute sequence.

The moving "blur" to the upper right of Capella is either a UFO or dirt on the camera lens/mirror. Subsequently checked the lens/mirror and no marks detected. (... cue Twilight Zone music!)

Tracker testing (2)

It's almost a year to the day since I posted the last update on testing. That's not because I've not being making progress, I've just not got around to writing about it. My bad.

The "horseshoe" star shapes I was getting suggested to me that the rod gimbals needed improving. These were the supporting pieces that held the threaded rod and allow it to remain perpendicular to the axis of the tracker itself. They were crudely pivoted on the points of screws that projected through from the sides of the block that held it to the main tracker arms. It's possible that if the axis of the pivots was not truly parallel to the tracker boards and perpendicular to the tracker axis then the turning of the rod could introduce some overall oscillation to the mechanism.

Eventually I decided to replace the pivots with hinges, that would create a more precise mechanism and hopefully fix the problem. Because the supporting pieces for the rod had been made separately and just screwed on to the tracker boards, it meant I could replace them with new ones made to accommodate the new setup. The images show how this was done. The centre of the rod aligns with the axis of the hinges, thus maintaining the correct geometry. The whole thing now moves much more precisely.

It's gratifying that now I've made these improvements to the construction, the tracker tracks properly with little or no correction needed to the geometric calculations built into the software i.e. I don't need to tweak the speedfactor through the DIP switches.

Here's a 60 sec tracked exposure of the Pleiades, as captured and after adjusting the input levels with the Gimp to remove the background fogging as much as possible.

I'm pleased with this, and I'm not sure that such a simply constructed tracker could deliver any better results.

As I mentioned previously, my suburban sky is horrible with light pollution, anything much longer than a 60 sec exposure is so fogged as to be a waste of time. However, my brother lives in one of the darkest skies spots in the country, so my next plan is to invite myself for an overnight stay. Roll on the clear weather!

Tracker testing (1)

My equipment is a Canon 5D3 with a 70-200mm L USM F4 lens at 200mm, ISO 800.

I started with 30 sec exposure.  Until these were looking good there wasn't any point in trying any longer exposures.

Initial results were disappointing, and inconsistent which made it difficult to understand exactly what was going wrong. There was a mixture of issues:

1. star images streaked inconsistently in the tracking direction
2. star image movement in other directions, sometimes in a sort of horseshoe shape
3. the whole star field drifting in the tracking direction from image to image

(3) is fairly clearly that the tracking speed is too slow (or fast, depending on the direction of drift).

(1) would also appear to be a tracking speed issue, although the inconsistency of the streaking made it difficult to understand quite what was going on.

(2) would seem to show movement in some other direction: the "horseshoe" shape wasn't always exactly that shape, and often with different orientation. Nevertheless it suggested some sort of oscillating movement, not random like a shaky tripod.

30 sec exposure of the Pleiades showing "horseshoe" errors

I concluded that there were two main issues:

The first that there was something wrong with the stepper motor, which could account for problems (1) & (3). I was already suspicious that it was not turning consistently. I also had tried tweaking the speedfactor setting on the Photon to fix issue (3), and had varied it by up to 20% before the star field stopped drifting (and even then it wasn't completely consistent). I had difficulty believing that my calculations for the code could be this much wrong. I decided there was something broken or slipping in the internal gear train so I replaced it (£10 for a pack of 5 on eBay!). It turned out that there are a number of variants of this ubiquitous 28BYJ-48 motor, and my original was one of the unusual ones, with a different gear ratio. This went some way to explaining some of the problems I'd had.

Secondly I decided that issue (2) was down to the play in the gimbal axes. I'd assumed that the quality hinges would prevent any lateral movement of the plates, but this appeared to be what I was seeing, driven by some oscillation in the gimbals. I'd crudely made them of a steel rod (actually a sawn-off nail!), so I replaced these with screws that fitted into the gimbal blocks tightly but still allowed free movement.

These two changes improved things significantly, with most of the issues disappearing.

30 sec exp. Pleiades: no tracking and tracked

 

120 sec Orion Nebula

Stars still don't render as perfect points, so more investigation needed. The 120 sec image of the Orion Nebula is encouraging. Testing is painfully slow because of the scarcity of clear nights.

Notes on Imaging Sessions

I estimate my night sky in Leamington Spa is a Bortle  class 7.

I record images directly onto my Linux computer via a 5m USB cable, using gphoto2 to control the camera. It means that, once I'm set up, I can stay inside in the warm :)

Barn door astrotracker project

I built myself a barn door tracker.

This is an astrophotography device to cancel the movement of stars caused by the Earth's rotation. Without something like this, photographs of the stars will rapidly show trails. There are many forms of equatorial drive to counter this movement, mostly costly, and a barn door tracker (aka a Scotch mount) is something that can be built cheaply as a DIY project (and I like those). Search the internet for more general info about them.

My tracker is based on the common design of two hinged boards (plywood in my case) driven apart by a straight threaded rod. The rod is an M6 size, which has a thread size (pitch) of 1mm, and is driven by a motor fixed to the lower board, and rotates in and pushes against a M6 nut fixed to the upper board. I was intending to fix the boards using a piano hinge, but it had too much play in it to be useful. Instead I used two high quality brass hinges, which are tight and have no play at all.

The simple rod type barn door tracker inherently suffers from the fact that the relationship between the length of the rod and the change in angle between the boards (i.e. the tracking angle) is not linear, but varies as the sine of the angle. This means the increase in the angle for a same amount of rod gradually decreases as the rod lengthens. The discrepancy is not significant for small angles but increases as the angle increases. Rods driven by a constant speed motor will therefore suffer this problem; there are more complex designs involving multiple boards that can reduce the error, but all this goes away if the motor speed can gradually increase to compensate.

At the time I chose to use a microprocessor and stepper motor, I don't think I really appreciated all this. Building something that needed a precisely geared arrangement from a fixed speed motor without any obvious means of finely adjusting it looked too hard, whereas I had a spare microprocessor lying around and have a background in IT. And importantly, this way looked way more fun!

So, this is what I did...

The rod is driven by a stepper motor controlled by a microprocessor. The motor (underneath the blue shaft collar) and upper nut are gimballed, allowing the rod to remain perpendicular to the axis of the hinge. This somewhat simplifies the calculation of the tracking angle.

The Particle Photon microprocessor drives the 28BYJ-48 stepper motor via a ULN2003 driver (the latter two £6 together on eBay). The motor is a real budget job but is the only stepper I've found that uses 5V and can be easily driven by a processor such as the Photon (and more commonly an Arduino).

Polar alignment

For polar alignment I use a green laser that was originally fixed to the top board, but I felt it was more accurate to fix it tightly against the hinge(s). One problem I discovered with green lasers is that they stop working in the cold (below around 5C). To overcome this, I bought a USB powered cloth heater to wrap around the laser.

Software control

The microprocessor cycles continuously through the code. In each cycle it calculates the angle between the boards required to match the sidereal turning rate and converts it into the amount the rod needs to turn. Using simple trigonometry this is translated into the length of the rod, the number of turns of the rod required to achieve it, and hence the number of motor steps. If the calculated number of steps has not yet been made, the motor makes one step forward. The tracker needs the rod to turn at roughly 1 rpm;  the processor cycles at a vastly higher rate than is needed to avoid missing a step.

Software control has at least two major benefits:

• The motor speed can be varied and determined by the tracking angle required; that is, the tracking angle determines the motor speed, and not the other way around as in a purely mechanical design. This means there should be no inherent error in the tracking speed.
  
• It's easy to fine tune the tracker's motion by tweaking the programming.
  

Other designs I've seen have the boards initially parallel so the starting angle of the tracker is zero. With mine, the angle does not start at zero because of the way I constructed it (I wanted space between the boards to install the electronics). The initial angle - formed by the hinge pivot and the gimballed fixings of the rod - needs to be added to the angle delta before the corresponding rod length is calculated, and then the initial length of the rod subtracted from the result. The code looks like this:

elapsedMillis = millis() - startMillis;
delta = 2 * PI * speedFactor * (elapsedMillis/millisPerSideralDay);
d = 2 * r * sin (delta+theta_init/2); // length in mm the bar should now be
turns = d - d_init;                   // number of turns (1mm per turn)
stepsNeeded = turns * stepsPerTurn; // number of steps to achieve this
while (stepsTaken lt stepsNeeded) { // are we there yet?
  setOutput(step);
  stepsTaken++;
}

The inaccuracy from not doing this correction is actually quite small, and very small for small angles, but nevertheless easy to fix in the code.

The variable speedfactor is a fudge factor, initially set to 1 but can be modified to fine tune the speed to match actual observation. A bank of DIP switches is wired into the processor, the settings of some of which can be read by the code and applied to speedfactor. The remaining DIP switches are used to control other aspects of the code, such as whether the Photon's wireless connection is enabled - needs to be disabled if a connection cannot be made.

 

Testing

Initial testing was disappointing, but more of that later.

Brown roll rims - why me?

Brown roll rim mushrooms are moderately poisonous and look disgusting. And for some reason, they grow in profusion on my side lawn. For someone who likes foraging for edible mushrooms, this is a great disappointment.

These guys obviously like my lawn. Perhaps it's because I've a large birch and beech tree growing nearby. The mushroom bible (Roger Phillips) says they grow to 12 cm. On my lawn they can grow to at least twice that size - this one was 29 cm across (the lens cap is 8 cm).

If I cut the grass at this time of the year I have to remove these mushrooms before I mow or - as I've discovered the hard way - they make a real mess.

I cleared them yesterday, the second time in four weeks, and filled two buckets...

... the mushrooms weighed 9.5 kg.

 Why couldn't they be ceps, or chanterelles?

Update 2025

It turns out that these are actually Paxillus obscurisporus, closely related but much larger and less common. They were identified first by Pat O'Reilly of First Nature, and latterly confirmed by Francisco Verenciano, one of the chief identifiers from the Warwickshire Fungi Group.

Bovedy meteorite

In a previous post I mentioned my search for information about a meteorite I actually saw fall while at Reading University. It's surprising that I found it so hard as it turns out to be quite notable. It's even mentioned in one of my astronomy books that I've had for years!

It's known as the Bovedy meteorite, after the place in Northern Ireland where the largest fragment was recovered, and fell on 25th April 1969 at around 21:25. A second fragment fell through a roof in Sprucefield. I'm obviously interested because I saw the meteor, and wanted to remind myself about it. (Note: a meteor is what you see in the sky, it's a meteorite when it hits the ground.)

I looked up the Times archive for the following day (now I know where to look!) and found a pretty lightweight item titled "The night a star fell on Ireland" that was a report from the Ballymurphy and Ballynahinch area of Co. Down. The internet however has far more useful data.

The most confusing thing for me is the track of the meteorite, because it doesn't agree with what I remember.

An article in Nature (3) includes a map showing the estimated track based on an extrapolation from the location of the retrieved fragments. This shows the meteorite crossing the English south coast at around Bournemouth and travelling in a NW by N direction. That this track is based on two hard facts about the meteorite, namely the location of where pieces fell, makes it pretty convincing. However, I'm unhappy with it because it conflicts with my memory of the incident. Memories can certainly be untrustworthy after 45 years, as shown by the fact that I remembered it happening in the summer (that was because it was in the evening and still light, or at least not dark, so I think I can be forgiven), but I do clearly remember where I was and what I was doing.

I was in St Patrick's Hall of residence at Reading University, playing bridge, and sitting facing the window. My room was in "K" block, where the windows face directly north-west, and my clear memory is seeing the object in the sky tracking to the left, and we watched it until it disappeared over the horizon. From this observation, the meteorite must have passed to the east of Reading, whereas the Nature track puts it 50 miles to the west, and so it would have appeared to track from left to right. I'm not sure I would have even seen it if this was the case.

Red track from Nature, blue track corresponds more with my observation

In the map, the numbered points are:
1 - Bovedy
2 - Sprucefield
3 - Shrewsbury
4 - Salisbury area
5 - Reading
6 - Preston
7 - Doncaster
8 - London
9 - Sussex area

So could the Nature track be inaccurate? It does look pretty convincing, but I can't shake the fact that it's not consistent with what I remember. The big problem with a track that is consistent with my memory is of course that it doesn't pass through the two fragment sites. This isn't necessarily impossible - fragments fall a long way and can be surprising affected by wind, although I have no knowledge of the wind conditions on that night.

Looking at other information, the The Meteoritical Society record (1) says "The fireball was seen all the way from Sussex through London, Doncaster and Yorkshire to Northern Ireland toward Belfast." - all the points in England well to the east of the Nature track. Another report (7) mentions an observer in Preston, Lancs, and another who saw it "over Shrewsbury". Also, it says "It was moving from ESE to WNW very rapidly." (like my track). The Nature track puts it travelling NW by W, a less oblique angle. These all suggest a more easterly track.

To be fair, the observations apart from mine aren't necessarily a problem: given the height and brightness of the meteor it would have been visible from a long way away. Also the greatest population of the UK lies to the east of the country, so sheer numbers would suggest that is where most observations would be made.

Perhaps I just have to accept that my memory is wrong. It may not have been as impressive as the Chelyablinsk monster but it was impressive nevertheless, and probably the biggest I will ever see.


There's also the question of how big the original object was, and how much of it was recovered. In The Data Book of Astronomy, Patrick Moore said "The Bovedy meteorite was well observed during its descent, but the main mass was not recovered, and almost certainly fell into the sea". Everything I've read only mentions the pieces found as "fragments" - I don't think anyone suggested that the object found at Bovedy was the main body of the meteorite. I vaguely remember from the time that some wild figures were kicked about (100 tones? 1000 tons?). More reasonably, the rounded shape of the Bovedy fragment suggests to me that is was part of a roughly football sized object, which would be around 20 kg given the normal density of stony chondrites.

In general - and it's so dependent on factors like size, speed and angle of descent - meteorites become visible at a height of around 100 km, and, assuming they've not burned up entirely, have slowed enough to stop ablating and become invisible at around 20 km and at a speed of 2-4 km/s, thereafter taking up to 3-4 minutes in free-fall to reach the ground (8,9).

Using these assumptions, it's possible to estimate roughly how far the main body of the meteorite may have travelled. It was still visible at Bovedy as it reportedly passed overhead (2), so if we assume it was 100 km high when first seen over southern England, and 20 km high at Bovedy, a distance covered of approx. 500 km, then this gives an angle of descent of about 10 deg.

Using all this, projectile dynamics (and taking into account air resistance) gives the following distances to the ground and time taken for a 20 kg spherical object, for various initial dark flight speeds:

Speed(m/s) Distance(km) Time(secs)
 2000         31         101
 3000         35         100
 4000         39          98

This would support Patrick Moore's assertion that it ended up in the sea.

In truth, I accept that it's probably nonsense to attempt calculations like these. Too many assumptions based on inaccurate data and guesswork. But I enjoyed doing the calculations!

References

1. The Meteoritical Society Bulletin Database record (http://www.lpi.usra.edu/meteor/metbull.php?code=5121)

2. The UK and Ireland Meteorite page (http://www.meteoritehistory.info/UKIRELAND/NEIRE.HTM)

3. Recent Fall of the Bovedy Meteorite, Northern Ireland, Nature, vol 23, July 25 1969 (images)

4. The Data Book of Astronomy, Patrick Moore, p248

5. 40 years since the sky fell on Ulster (http://www.newsletter.co.uk/news/regional/40-years-since-the-sky-fell-on-ulster-1-1884295)

6. The night a star fell on Ireland, (London) Times newspaper article, April 26 1969

7. Turning UFOs into IFOs; Part 1: Fireball Meteors (https://planetpreternatural.wordpress.com/tag/bovedy/)

8. Fireballs and Meteorite Falls, International Meteor Society (http://www.imo.net/fireball/meteorites)

9. American Meteor Society, (http://www.amsmeteors.org/fireballs/faqf/):
"At some point, usually between 15 to 20 km (9-12 miles or 48,000-63,000 feet) altitude, the meteoroid remnants will decelerate to the point that the ablation process stops, and visible light is no longer generated. This occurs at a speed of about 2-4 km/sec (4500-9000 mph)."

 

Update Feb 2024

I heard from Paul Littler who recently contacted me after reading this. He also saw the meteor that night from where he lived not far from Merseyside, and as with me it made a lasting impression on him. Paul had done more research than I'd done, and had contacted the Armagh Observatory where most of the recovered pieces are now kept. They told him that the meteor would have been the size of an American Fridge when it entered the atmosphere. A quick calculation using the average meteorite density of 3 gm/cc yields a size of around 3 metric tons!

This seems enormous, and you'd think one of the largest seen to fall on the UK. But meteors are recorded by the size of recovered meteorite fragments, without much or any speculation of initial size, and in terms of recovered weight (3 fragments with a total weight of around 8 kg), the Bovedy meteor ranks only 11th on the UK list. Nevertheless, since some or most of it probably landed in the sea, it may well still be one of the largest observed falls.