Astrophotography with the home made tracker

 It's been ages since I posted on this subject - there never seems enough time to do everything, especially since I retired (an often heard complaint!). Which is a shame because eventually I got the tracker to work quite well.

 The main problem turned out to be the stepper motor. The original was a one-off purchase through eBay, and I began to suspect that the motor was not turning evenly. These are really cheap units of questionable quality, so I got some more from a different source. There seems to be many manufacturers/retailers of this motor, so it's probably pot-luck as to how good they are. I bought a pack of 5 which came together with the ULN2003 driver.

 Having replaced the motor with one of these, results were immediately improved - to the extent that the speed adjustment controls I'd built-in didn't need to be used as the tracker and software behaved pretty much as designed.

Stability

 I think any remaining image issues are down to the lack of stability of the mount. I'm using a decent camera tripod (Manfrotto 190XPROB with an XPRO geared head) but it's just not up to handling the combined weight of the tracker +camera + lens. My camera is a Canon 5D mk3 and from my small lens collection the only suitable one is a 70-200mm F4 L zoom, the combined weight being 1.7kg. I do have a longer lens but it's far too heavy. The tracker is 1.5kg  so the total weight is 3.2kg (the assemblage is not well balanced) and I'm sure it moves even in a slight breeze. If I lived somewhere with good skies then I'd build a solid pier as a permanent mount - but then I'd already have a decent telescope, observatory ...

 Photos

Because I'm limited to a 200mm lens, or 4x magnification, there aren't really any deep-sky objects available to me. I'm also restricted to what parts of the sky I can photograph at home because of the need to see Polaris to orientate the tracker, and my house inconveniently gets in the way. So I've used the tracker to photograph solar system objects that would normally be too faint to see - e.g. Neptune, Uranus and now some asteroids. (Remember that my suburban sky is not good - Polaris is only just visible to my naked eye.) It's nice to see how sharp (or sometimes not!) star points the tracker can produce. Fortunately my house restricts me to viewing south, and thus the ecliptic.

This recently taken image surprised me in its ability to show some of Saturn's moons.  I like it! I use Stellarium to locate and verify the objects in view.

 

Another showing Jupiter's moons, and compared with an untracked variant.

 

... the satellite positions shown in a screen capture from Stellarium:

 

This blog doesn't let me include images that can be popped out to enlarge them, so these and more images can be found on Flickr, here. 

 So nothing particularly impressive, but nonetheless show that it can work.

Chris

 

 

Sound Recorder update

This is an update on the ESP32-based sound recorder and problems I've encountered.

File system

As the number of files on the SD card increased over a number of days of recording, the files got shorter and noisier (jittery). I put this down to the battery running down and the processor getting insufficient power. I eventually discovered that the problem was that writing to the SD card took longer and longer as the number of files increased. This is a known issue with the SD file system.

The code reads from the mic and writes to the SD file for a set amount of time e.g. 3 minutes, assuming that the writing takes negligible time. When the write started taking a significant amount of time then less data was being written to the file. As the write time got longer, less and less data was written to the file in the 3 minutes.

The solution was to arrange the files into subfolders, the problem being the number of files in a folder (including the root folder) and not the total number of files on the card. At least one place online said that this did not fix the problem, but it does.

I now create a folder per day, with the assumption that I won't be creating more than 50 files per day. I don't know how many files are needed for writing to start slowing down, but 50 is well within this number. The creation of one folder per day also overcomes the problem of creating artificial file names that had to combine date and time. Now, the folder is in the format YYYYMMDD and the file name hhmmss.

DS3231

The DS3231 RTC lost time over a period. It appeared to lose time while the ESP32 was in deep sleep. I believe this was because the battery in the DS3231 is not getting charged during deep sleep and eventually ran out of juice (the recorder spends most of its time in deep sleep). I noticed that the prototype recorder, which has a non-rechargeable battery, doesn't have this problem, although perhaps it's never on long enough to show this issue. Anyway, leaving the recorder on power (and not in deep sleep) when back at base seems to be enough to charge it.

ESP32 clock and RTC out of sync

The time shown in the file name and the file system creation time drifts. I think this is distinct from the previous issue and caused by the ESP32 clock being inaccurate.

On initial boot, the time is obtained from the DS3231 and set into the ESP32. This is needed because the SD file system gets its time from the EPS32. Initially these are obviously in sync. This only happens on initial boot and not when the recorder reboots after deep sleep.

One internet source says:

This means the ESP32 internal RTC is 31 seconds ahead of real time after 1 hour of deepsleeping.

 so after a number of days the ESP32 clock will be appreciably ahead of the correct time.

The solution is to set the ESP32 clock on every boot.

Batteries

I've yet to determine how long batteries last. The problem with the file system was masking any testing. The recorder is now powered by 2x3300mAh batteries in parallel and I've yet to discover their limit.

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. It's also inaccurate over longer periods, so needs to be reinitialised frequently, 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.

 

PCSecrets

PCSecrets is a PC application that holds information that you want to keep secret - protected by a master password and strong encryption.

The program is designed to be a PC counterpart of the Secrets for Android app. It uses the same data structure and provides a synchronization mechanism that allows easy transfer of secrets between the two. For those who find the PC environment  more comfortable for data entry and editing (i.e. keyboard/mouse/screen), PCSecrets provides an alternative environment for managing your secrets. Synchronization is also effectively a form of backup.

Encryption

PCSecrets uses AES-256 bit encryption which is the strongest commercially available encryption scheme. In addition it employs bcrypt, which implements key stretching with an adaptive key setup phase.

The purpose of the bcrypt algorithm is to introduce artificial but complex processing that takes a calculated amount of time into the key hashing processes. This introduces a finite delay into the setup of the encryption and decryption ciphers that will be used. In PCSecrets, this setup phase is configured to take 1 second (as measured on the current computer) which is not really perceptible. However, the consequence of this delay is that any attempts to break the encryption by guessing the password are considerably slowed down, since each password guess is forced to go through the same processing to create a decryption key.

This makes it highly resistant to dictionary attack.

(See "key stretching" and "bcrypt" on Wikipedia for more information.)

Features

Features of PCSecrets are:

• the same strong encryption used by Secrets for Android
  
• a form of cryptographic plausible deniability, whereby a hidden second set of secrets can exist that is protected by a different password
• synchronization with multiple Secrets for Android devices i.e. phones, tablets
• synchronization data is always fully encrypted
• automatic backup on save
• import and export of CSV data
• written in Java, so can be executed on any system with a suitable Java Virtual Machine

An individual secret is a collection of text fields. These have names such as userid and password, and lend themselves to data used to access Internet sites, but this is only a suggestion and the fields can be used in any way you want. In particular, the note field is provided as a catch-all for holding any unstructured text. The exception is the first field, the description. This is used as the name of the secret, and must be unique.

Installation

Download the executable jar file from (email me for the moment) and place on the desktop or some other suitable location. There is no install process as such - just execute the program by using the Java executable already installed on your computer.

If the default open action for a .jar file on your computer is to open using the Java executable, then simply double-click on the jar file. Otherwise right-click on the .jar file and select the Java executable to open with.

If Java is not installed then you will have to do this first. You can use for example the  Sun Java or OpenJDK.

Getting Started

When first run the program will prompt for an initial password. Try not to use a simple password - a mixture of letters, numbers and special characters but no spaces (leading, trailing or embedded) - and don't forget it! Subsequent executions of the program will require the same password to be provided - if you can't then your secrets will not be accessible. The password can be reset by providing a new one, but all existing secrets will be lost. There is no way to recover a forgotten password.

Optional second set of secrets

You can initially provide two passwords i.e. separated by a space. In this case you actually create two sets of secrets, independently encrypted and independently accessible. When you subsequently start PCSecrets, you can provide either password to access the corresponding set of secrets.

The two sets of secrets are stored as a single chunk of binary data. Externally it is not detectable that two sets of secrets exist, so if someone were to force you to reveal the password(s) to your secrets, you could deny that a second set of secrets existed without anyone being able to prove otherwise. This is known as plausible deniability,

The Main Window

The main window shows a list of secrets on the left, and a form showing the details of the selected secret on the right. Beneath these is a row of buttons. The buttons below the list apply to your secrets as a whole; those below the form apply to the current secret or data in the form.

Creating a secret

To create a new secret, simply type your data into the form and click "Create". The description of the secret becomes its name, that is shown in the list on the left. (The term "description" is used to make it compatible with Secrets for Android - in data terms it is the key of the record.) The set of fields that make up a secret are the same as used by Secrets for Android, and all values are optional apart from "description".

Create will be ignored if a secret with the same description already exists.

The "Clear" button is provided as a quick way to clear the form values before creating a new secret.

Updating a secret

Select the secret by clicking on its entry in the list. Make your changes and click "Update". If you change the description, you are now dealing with a different secret (because you've changed the key). If it doesn't exist, update will be ignored. You can copy a secret by selecting it, giving it a new description and clicking "Create".

If you modify a secret but forget to click "Update", the changes will not be saved.

Deleting a secret

Select the secret (or type its name in the description field) and click "Delete". If you attempt to delete a secret that does not exist, the request is ignored.

Saving

Click "Save all" to save changes to disk. If changes have been made and you exit the program without saving, you will be prompted to do so. If you do exit the program without saving, changes made since the last save will be lost.

Import and export

Secrets can be imported and exported in CSV format. This is a simple and commonly used data exchange format.

Import

Select File->Import.

Use the selection dialog to locate the .csv file to be imported and click "Open". The subsequent Import dialog provides for control over how fields in the imported file are mapped to Secrets fields.

The Columns section  shows how many fields there are in the imported file (by analysis). It also shows the contents of the first record, to determine if a header record is present. If a header exists, and it provides field names that match the Secrets field names (Description, Id, PIN, Email, Notes) then a mapping between these matching fields will automatically be created. A Timestamp field can also be provided to give a record a last updated time.

If no header exists, the fields are identified by position, #1, #2, etc. The mapping of fields is sequential.

To change any mapping, click the Input field name in the Mapping section and select, from the dropdown, the correct field.

When the mapping is correct, click "Import".

Export

Select File->Export.

Choose a location for the exported file, provide a file name and click "Export".

Synchronizing with Secrets for Android

(This feature is currently undergoing testing and is not yet available with the current version of Secrets for Android. It will also require an additional app, the PCSecrets sync agent, to be installed on the Android device alongside Secrets for Android)

To synchronize your secrets, click the PCSecrets "Sync" button and the program will wait for a mobile device to connect.

Secrets are sent to and from the device only in encrypted format, and the same password for encryption and decryption must be used at each end. This does not have to be the same as the one used in either PCSecrets or Secrets for Android. By default PCSecrets will expect the device to use the PCSecrets password. Alternatively, a preference can be set so that a different password can be provided when "Sync" is clicked. Either way, the password to be used has to be configured in Secrets for Android so that both ends of the exchange use the same password.

The program will automatically try to make the secrets in each location the same. In doing this, it follows these rules. A secret that:

• exists only in one location is created in the other
• has been updated in one location is copied to the other *
• has been deleted in one location is deleted from the other *

* provided that the secret in the other location has not itself been modified since the last sync operation. If it has been, a conflict exists which the program cannot resolve automatically, and you will have to indicate what you want it to do. The program will open the sync window so you can do this.

Normally the sync window will only be shown if a conflict exists that you have to resolve. If there are no conflicts the sync operation will complete automatically. Alternatively, you can set a preference so that the sync window is always shown even though they are no conflicts. You may want to do this so you can see exactly what is going on.

The Sync Window

The sync window shows the list of all secrets on the left, and two panels on the right which show the contents of the selected secret on the PC and on the mobile device. Items in the list are colour coded to show their status, and checkboxes can be used to show or hide the different categories.

By default only secrets that differ between platforms are shown, although all secrets can be shown by checking the "Show unchanged" checkbox.

Everything except conflicts are shown for information only and require no action - if secrets differ, the program determines where the latest version is and automatically uses it to update the other location. Note that the content panels are normally read-only; only in the case of a conflict will you have the opportunity to modify the contents of a secret.

Conflicts are always shown and must be resolved before the sync operation can be completed. If you cancel the sync operation no changes are made.

Resolving conflicts

A conflict occurs if a secret has been modified on both the PC and device, or been changed on one and deleted from the other, since the last sync operation. In both cases, the user has to indicate how to proceed, as follows.

If modified in both locations

Select the conflicting secret in the list window. The contents of the secret on PC and device are shown in the corresponding forms. You should update the PC secret to reflect the correct secret contents, and click "Mark as merged". If the PC secret is already the correct version, just click "Mark as merged". If the device secret is already correct, then click "Copy to PC Secret" and then "Mark as merged".

When the sync completes, the PC secret will replace the device secret.

If modified in one location and deleted from the other

Select the conflicting secret in the list window. The PC and device panels will show in which location the secret has been deleted. Your choices are:

• If the deletion is correct i.e. you want the secret also to be deleted from the location where it remains, click "Confirm deletion"
• If the deletion is not correct i.e. you want the secret to be reinstated in the location from where it was deleted, click "Undelete". When the sync completes, the secret will be reinstated from the existing copy.

Sync timeout

By default the mobile device will only wait for two minutes for the sync operation to complete. This is so communication won't hang forever if sync was selected and PCSecrets is not active, or if there is some communication problem. You can change this value in the agent configuration in Secrets for Android.

If the operation does timeout before it completes, no changes are made. The operation can simply be retried.

Sync with two sets of secrets

Secrets for Android does not support the idea of having more than one set of secrets. Sync simply operates with the set of secrets that is currently being accessed.

 

Preferences

Access via the File->Preferences... menu option. The Preferences window is divided into these sections:

Secrets
Allows you to specify the location of the PCSecrets directory.

Sync
Here you can change the port numbers used by the program. This would only normally be necessary if the ports are in use. Note that this requires a change to the Secrets for Android sync agent configuration so the same port is used.

Log Level
You can set the log level for diagnostic purposes. The log is created in the home directory and named java{n}.log.

By default the log level is set to warning. Be aware that with the log level set to a finer level (info or fine) diagnostic information may be written to the log that could be used to compromise the security of your secrets. So do not as a matter of course set the log level below warning, and if you do set a lower level for diagnostic purposes, make sure you reset the log level afterwards and securely delete the Java logs.


Backup
Backups can be automatically created whenever a save is performed. The number of backup files that are kept can be specified - when the number is reached, the oldest file is deleted when a new one is created.

Meteors

The other day's huge meteor in Russia made me remember the two impressive meteors I've seen during my life. Both were back in the 1960s.

I was lucky enough to grow up in the countryside, where skies were dark and it was difficult (for me anyway) not to be interested in the night sky. This was where my interest in astronomy started. My mother liked to remind me of the time, after I'd made my first telescope, that I sat my grandmother on the front lawn on a dining chair in the pitch black, and explained to her the amazing things she could see through my telescope. She was very patient and a perfect student even though I imagine she was bored rigid.

The night skies there were such that you only had to stand and stare at the sky for a minute or two, as I often did, to see your first meteor. One gets the impression that this is far more frequent than people talk about now. I can't believe that the frequency of meteor has change over such a short space of time, so it's probably just down to the darkness of the sky and young eyesight. I saw lots of meteors.

Anyway, back to the story. One night, when in my early teens, I was on milk duty - taking the family milk can to the local diary where it was left to be filled by the morning milking, and then collected before breakfast. Suddenly the world lit up around me, brighter than a full moon, and I looked up to see a bright meteor overhead, with pieces in the trail where is was breaking up. It looked something like this:

Because of its brightness it would probably be described as a bolide, which sounds more impressive even though it's not an officially recognized term. A bolide is a very bright meteor, brighter than the moon. This was undoubtedly the brightest meteor I'd ever seen - up to that time.

Fast forward a few years to my time at Reading University (1966-1969). One evening I was playing bridge in my room in hall of residence when through the window I suddenly spotted a bright light crossing the sky leaving a smoke trail. Bearing in mind that it was still light this was obviously something big, and reminds me now of (a lot smaller and without the Hollywood sound effects) the meteor in "Deep Impact", and definitely similar looking to pictures of the Russian one. We all returned to our game knowing that we'd seen something quite extraordinary. The next day the news reported sighting of the meteor ("fireball") across England and Wales. It had crossed the country from south-east to north-west, passing over north Wales where falling pieces were reported to have started fires in the mountains, and ended up in the Irish Sea north of Anglesey. There had been numerous sightings and calls to the police (presumably to arrest it?).

My memory of the precise details of the event, and when it actually was, grew hazy over the years, and about 20 years ago I went through the Times newspaper archives at my local library to find the reports of the event. I eventually did found it, made notes and carefully filed them away for safe keeping. So safe, it seems, that I can no longer find them, which I'm really frustrated about. I feel another visit to the library coming on. If anyone reading this remembers the event, please let me know!

Update 20/04/2014

Last year I spent two days trawling the Times archives again and frustratingly found nothing. Last night I happened across this post again, idly tried an internet search (something I'd done many, many times before) and ... found it! Internet searches are so dependent on what you type in - I guess previously I'd just used the wrong words :(

Anyhow, the meteorite event was named "Bovedy" from the place it (or at least fragments) landed in Northern Ireland. The date was actually 25th April 1969, at 21:25; my memory is that is wasn't dark and this would tally as at this time it would have been dusk (sunset about 20:15, end of twilight around 22:30, according to the tables). The official record in the Meteoritical Bulletin (http://www.lpi.usra.edu/meteor/metbull.php?code=5121) says this:

"The fireball was seen all the way from Sussex through London, Doncaster and Yorkshire to Northern Ireland toward Belfast. It was moving from ESE to WNW very rapidly. There was a swishing noise and people reported explosions. The largest fragment of the meteorite weighing 7,400 g was found near the village of Kilrea, Londonderry County. Searches are being conducted."

This description agrees with what I remember, but then I started to find information that didn't, so I read more and wrote another post on the subject.

A better mousetrap

Many years ago I made a humane mousetrap ago because my family don't like the idea of the spring "snap" trap. I don't really either, partly because when I was a kid my father used one and I saw plenty of mice that had not been killed cleanly . Besides, I just like making things.

This trap is pretty old now and no longer works reliably, but it's given good service and in the 15 years or so it's been used, it's caught probably over a hundred mice. However, the old design was over complex and a bit tricky to set. It had a drop-down door held open by a thin bolt that was withdrawn by the mouse walking over a see-saw. Setting it was always a balancing act between having it trigger by itself or not having it trigger at all. I thought I could do better.

The old trap showing signs of wear, and being eaten

The new design has a pivoted door, is simpler, smaller and seems to work well, so I'm describing here how to make one.

The new one is much smaller!

Here's the schematic:

The trap is a simple box - two sides, base and back - with a hinged door and hinged wire mesh on top. The top could be another piece of ply, but the mesh lets you see into the trap when the door is closed. The top needs to be able to open so the see-saw can be removed for cleaning - it's essential that mouse droppings are removed from under the see-saw or it will not "rock" properly.

The materials were chosen from scraps I had lying around (I hate throwing away offcuts). The carcass of the box is made from 9mm plywood, and the see-saw and door from 5mm ply. Neither of these thickness are critical although the mesh is hinged with small staples in the top of the back, so this cannot be much less than 9mm. If you do change the thickness of any pieces, check that this hasn't changed any of the other dimensions.

The box carcass (sides, back, base) should be simply glued together with wood glue.

Cut the see-saw so that it fits inside the box with about 1mm clearance from the back and sides. Fit the wire door support next. It's a square hoop that the door rests on when open. I made this and all the other wire pieces from some 1.6mm galvanised wire I already had, just pushed into holes drilled with a 1.5mm drill bit. This was a bit lucky - the combination of bit size and wire size meant that the wire is held firmly in the hole without anything else being needed. You may need to search around to find something suitable. Thin coat hanger wire may work.

With the door support in place, find the balance point of the see-saw by placing something suitable under it. Then mark the position for the screws as 2-3mm back from this balance point, so that the see-saw will naturally rest forward but will tip back with the weight of a mouse. Place the see-saw in the box as shown in the diagram, and check it balances easily on the screws and doesn't touch the sides, then press firmly down on it so the screw make indentations in the base. Don't press too hard - you are just trying to make indents so that the see-saw will easily locate itself when you put it back after cleaning.

Drill holes in the sides for the door pivots - make sure that the pivot line is at right angles to the sides or the door will catch against the sides. Hold the door in the right position and then push wire through the holes on each side so that they mark the door where holes should be drilled. The holes in the door should be wider than the wire so the door swings freely. You can see from one of the picture that my door is sloping slightly backwards because it's fractionally longer than the opening. This actually works well - you don't want the door to be able to be completely vertical as it could be pushed open.

Once the door is in place, bend the door support as needed so that the door just rests on the wire when the see-saw is at rest (forward), and closes when the see-saw is tipped. You will need to fiddle around with this to get it just holding the door open so that the slightest movement of the see-saw will release it.

Cut some wire mesh to cover the top and loosely staple to the top of the back so that it can hinge back to give access to the inside. Drill holes in the top of the sides to take wire turn catches to hold the mesh in place.

Finally you should seal the inside with water-based varnish. Mice will make it wet and messy when they're inside.

For bait you don't need anything special - contrary to popular opinion, mice don't have any special preference for cheese. I just use a few crumbs of digestive biscuit.

I release the mice a little way away from the house so I can be sure they don't come back. I've no idea if they are likely to, but I did read a comment left by someone who had bought a humane trap. They were complaining that it was useless because the mouse kept returning. This person didn't seem to consider that they may all have been different! In my experience it's normal that you don't just have one mouse -  "catch one, catch more".

That's it. I hope it's useful.

Good day's foraging

Mushrooms are late this year. A visit to the New Forest at the beginning of October drew a complete blank. Maybe the wet weather at the end of September has at last encouraged them to show - the profusion of Sulphur Tufts and Brown Roll Rims in my garden would suggest so. I spent a few days searching around my local woods in Warwickshire for something edible, and after drawing a few blanks, eventually this morning came up trumps.

Shaggy Parasols, Horse mushrooms (or maybe the similar Agaricus macrosporus), Wood Blewits and Oyster Mushrooms - and some Sweet Chestnuts. Shaggy Parasols can apparently cause stomach upsets in some people - fortunately no-one in my family.

A wild mushroom risotto is already on the menu!