Latest Posts
Meteor Camera Highlights
- Details
This page lists some of the highlights, significant detections made by my Global Meteor Network Cameras. All in reverse chronological order.
Perseids Meteor Shower - 2026 July - August
The peak (20260812) of the Perseids coincided with a solar eclipse (partial in the UK) and associated new moon and for a change, a mainly clear night.
Last year, I only had one camera operational that actually went live just in time for the 2025 Perseids peak. This year, with 3 cameras operational and 2 pointing in a more favourable direction, the results were outstanding. The first Perseid was detected on the 20260728 and the last on the 20260720, a window lasting just over 3 weeks.
The images below are from the night of the 12th through to the 13th August, the official peak, although counts were also high on the preceding and following nights.
Perseid Meteors were first detected on 25th July and the last on 21st August
The peak was over the 12th and 13th August.

There are 3 GMS (Global Meteor System) cameras in use, UK00DA pointing SW, UK00DE pointing NW and UK00DU pointing NE. Each camera has a field of view of about 88 x 42 degrees.

This a galactic map and clearly shows the source of the 202 Perseid meteors detected by the SW pointing camera. The following image is stack of each frame that detected a meteor.

Aircraft trails are visible but these are discounted by the detection software.
The next two images are from UK00DE, pointing NE.


Finally the last 2 images are from UK00DU, pointing NE.


Quadrantids Meteor Shower - 2026-01-03
Following on from the Geminids, I had another treat at the peak of the Quadrantids Meteor Shower. It was certainly not as impressive as the Geminids but not bad for a nights work while I was asleep. Incidentally, the Quadrantids refer to a constellation (Quadrans Muralis) that was demoted by the International Astronomical Union when it devised its official list of constellations at its inaugural meeting in 1922. The shower radiant is now in the constellation of Bootes.
UK00DA (SW Facing Camera)

and the radiants plotted as:

The NW facing Camera, UK00DE captured this:

and the radiants plotted:

A total of 282 meteors captured from this very short lived shower. Quite a good result considering it was cloudy part of the time.
Geminids Meteor Shower - 2025-12-12
Up until this date, my record for the number of meteors captured in one evening was about 150. This blew that record out of the water.
UK00DA, facing SW recorded this:

with the radiants determined by this chart:

455 meteors detected of which 338 were Geminids.
UK00DE, the NW facing camera also detected, on the same night:

with the radiants determined:

Another 342 Geminids. The total for the evening was:
Total: 928
Geminids: 680
Sporadic: 140 (no common source)
20260912 013002UT Fireball
- Details
My NW facing GMN Meteor Detection Camera (UK00DE) detected a Fireball at 01:30UT on the 20260912. A very bright object at Magnitude -5.8.

The Meteor was tracked by a small number of stations (approximately) over Llandudno heading towards Welshpool. It was approximately 50km high at the end of the detection heading downwards at about 45 degrees. The camera has a capture are of 88 degrees horizontal and 42 degrees vertical.
Very right objects like this are not recorded as meteors as they are above the brightness threshold. The data needs to be manually checked. for bright Fireballs.
A short video of the event has been uploaded to YouTube.
The flash is very brief as each frame in the video is 10 seconds long. The image above was used to compile the video.

My camera is the green dot on the map, I was perfectly placed for this observation.
The orbital analysis for this observation has been published here on the UM Meteor Network Archive:
GMN - Global Meteor Network
- Details
Background
I am interested in most things astronomy related and this caught my attention a couple of (or perhaps more) years ago. At the time, I thought it looked an expensive project and it went on the backburner for a little while. I really should have read the GMN WiKi a little more closely. In the scheme of things, this is really not an expensive project, especially when you consider the return and involvement in a true Global Citizen Science project.
What is it?
Broadly the system consists of a (very) low cost security camera with a very wide angle lens, LAN connected through to a Raspberry Pi 4 or 5 with an external internet connection to central data processing servers for the GMN, plus, for UK users, connection to the parallel UKMon (UK Meteor) infrastructure. I have assembled two camera systems - one pointing South West (identified as UK00DA) and the other pointing North West (identified as UK00DE).Their purpose is to detect and record meteor trails accurately enough, so that (with other remote systems) an accurate trajectory of the meteors original orbital path can be calculated. An additional and very important benefit is that any likely meteorite falls can be tracked and the meteorites recovered
The continuous (hours of darkness) image data collection from the camera is processed by the Pi identifying apparent meteor trails against a stellar background. There are two levels of data analysis, a quite intensive pre-upload processing phase that is carried out on the Pi. This involves eliminating anything that does not appear to be a meteor, for example aircraft trails, satellites. A meteor has a quite distinctive visual trail, it is normally very short duration, typically less than 2 seconds plus the visual cue of a trail that 'fades in' to maximum brightness then either terminates abruptly or "fades out" back to nothing. This contrasts with aircraft (usually flashing lights and a trail duration of many seconds) or satellites that may have a trail duration of several minutes. Once a valid trail has been captured, it is possible to backtrack this trail establish the meteor shower source or whether the meteor was sporadic.
The camera is set to have a fixed shutter speed. What this means is that each sequence is formed from a set of frames of CMOS Camera rows and columns of data captured contiguously at a fixed timing. This allows the processor to determine the apparent velocity and direction of the trail against the stars that are captured within that sequence of frames. Frames are analysed in blocks of 10. Each frame is analysed, if there are insufficient stars visible (a minimum of 20 required for astrometry purposes) or no trail detected, the frame is nominally discarded.
Before you can start, the camera needs to be located, fixed and then prepared. There are 2 aspects of this, the first is very simple. From an image produced by the camera, simply create a mask, blacking out everything that isn't sky. The second task is to calibrate the direction that the camera is pointing. From an image previously captured on a clear night showing lots of stars, create a calibration file that fits matched stars to those on a downloaded star map. The process compensates for distortion induced by the use of a very wide angle lens. This is a very worthwhile and enjoyable task
Walkthrough
This is a walkthrough of events that occurred on the night of the 2025 October 25-26.

A typical stacked image of all captured frames for that night looks something like this. You can see that the image is swamped by aircraft trails.
This image is a stack of the 104 detected objects that were shortlisted as meteors. There are a few aircraft trails, but possibly, they just happened to be in frame at the same time that a meteor appeared.

After filtering, the image looks like this. Star trails can be seen as an arc of dots against the black sky background. Clearly, there are some aircraft visible but nothing resembling a satellite. This is a filtered image from all the objects detected that night:
Each trail is then compared against a map of background stars and its apparent velocity and position is calculated. The Pi then identifies the likely cosmic source and if possible, the 'parent' meteor shower source.

This is a visual report of the meteors detected on the night of the 2025-10-25/26 with the source shower identified or the number and source of any sporadic meteors.
The following day, after the capture phase and initial processing has completed, the data is then uploaded to the central data processing servers and each potential meteor is compared with other cameras that may have detected the same trail The system has the capability to detect meteor trails up to about 300km distant and down to about magnitude 4. Aircraft and other flying objects that remained following the local processing phase are now eliminated as these fly much lower (usually less than 10km altitude) than meteors. Satellites orbit at a minimum altitude of about 160km and these are easily isolated and are now eliminated as accurate height information cannot be determined from a single camera. Meteors burn and form trails somewhere between 75km and 120km altitude. The elimination phase is performed by triangulating the trajectory with 2 or more RMS systems pointing in the direction of the meteor.
The data is then processed and orbital parameters determined. This ongoing iterative process allows the real scientists to determine, with a great deal of accuracy, the source of the meteor and record this accordingly. The Global Meteor Network home page details how the data is captured and compiled.
the UKMon archive website has a search facility that enables a user to examine the meteors detected on any specific date (or date range). The data for my camera UK00DA for the night of 2025-10-25 provides this result.

Selecting the match for 2025-10-26 04:16 provides a detailed analysis for a particular meteor including (where the meteor was bright enough), the image that was captured by my own camera.


Captured moving from the SW to NE with Orion nicely framed.
Next stage in this project will be a 3rd camera pointing East. One for the spring.
Radio Meteor Detection System
- Details
This is a short article describing my new Radio Meteor Detector. The system detects meteors as they enter the atmosphere and burn up. To be strictly honest, we are performing a secondary observation, detecting a reflected radio signal from an ionized atmospheric trail caused by the meteor superheating the air as it burns up.
In this case, the originating Radio Signal is a transmission on 143.050MHz by the Satellite Detection Radar Station at Graves in South France, operated by the French Government. See this Wikipedia article for more information.
Hardware & Software
The system is quite simple. The processing power is provided by a Raspberry Pi 4 that I bought off eBay at hugely discounted price. Importantly, a decent high current "wall-wart" power supply is used that provides (allegedly) up to 5 Amps at 5V. Networking is CAT5E back to a Cisco 2960 Switch and operational connection is by VNC. The system is therefore 'headless', there is no need for a monitor, keyboard or mouse after the Raspberry Pi has been configured. The hardware sits in a plastic box with multiple large air vent holes cut into the lid. A single large heatsink module (no fan) is used for cooling. The average processor temperature is about 41 degrees Celsius.

The radio module is a nooelec SDR dongle, acquired from Amazon UK.

The descriptor for the item is:
Nooelec RTL-SDR v5 SDR - NESDR SMArt HF/VHF/UHF (100kHz-1.75GHz) Software Defined Radio. Premium RTLSDR w/ 0.5PPM TCXO, SMA Input & Aluminum Enclosure. RTL2832U & R820T2 (R860)-Based Radio
This plugs into a spare USB slot on the Raspberry Pi4. The RF connection to the aerial is vis a N type bulkhead connector with a trailing SMA connector that screws into the other (RF input) end of the nooelec dongle.
The software is the Raspberry Pi Radio Meteor Detector which is available from GitHub.. This is very easy to install and configure, sitting on a standard Raspberry Pi image.
Antenna
The antenna (aerial) is a 5 element Yagi beam, constructed using parts reused from a 144MHz amateur Radio Antenna which I bought many, many years ago. It is mounted just below roof apex height and is pointed due South.
![]() |
![]() |
![]() |
The images show the general arrangement. The boom that supports the elements is aluminium box section, the reflector and director elements are held in place using 3d printed sleeves that locate and isolate the elements onto the boom.. The driven element uses a gamma match (centre photo). This basically matches the 50 ohm cable and receiver impedance with the impedance of the 'driven' dipole element. This is not essential for a receive only system, a simpler method of connecting the coaxial cable to the aerial could be used.
I used the calculator located here at the Changpuac website.
The results from the design input are:
DESIGN DATA FOR YOUR YAGI
https://www.changpuak.ch/electronics/yagi_uda_antenna.php
Javascript Version 12.01.2014, based on Rothammel / DL6WU
-------------------------------------------------------------
Frequency : 143 MHz, (useful from 140.14 to 145.86)
Wavelength : 2098 mm
Rod Diameter : 6 mm
Boom Diameter : 20 mm
Boom Length : 1678 mm
d/lambda : 0.003 ( min.: 0.002 , max.: 0.01 )
D/lambda : 0.010 ( min.: 0.01 , max.: 0.05 )
Elements : 5
Gain : 8.8 dB (approx.)
-------------------------------------------------------------
Reflector Length : 1025 mm
Reflector Position : 0 mm
-------------------------------------------------------------
Dipole Length : 1011 mm
Dipole Position : 420 mm
-------------------------------------------------------------
Director #1 Length : 977 mm
Director #1 Position : 839 mm
-------------------------------------------------------------
Director #2 Length : 977 mm
Director #2 Position : 1259 mm
-------------------------------------------------------------
Director #3 Length : 977 mm
Director #3 Position : 1678 mm
-------------------------------------------------------------
Directors / Parasitics are isolated.
Please choose an isolator thicker than : 10 mm
A five element antenna provides more gain (than a yagi antenna with less elements) but at the expense of a narrower beam width. More gain means that weaker trails can be detected, narrower beamwidth means that the aerial has a narrower field of view. Swings and Roundabouts.
An internet search will bring up other designs, often made of a softwood boom and 'element supports' with wire used for the electrical elements.
In use
I had the system mainly built and configured and soak tested on my lab bench. The purpose of Soak Testing is to identify any problems with the hardware and software which can be resolved before the system is located in its final operational position. It also gives me the opportunity to 'tweak' the software and settings to ensure that the data that I am collecting is valid. One of the problems with SDR radios is that they can generate their own interference which could give rise to false positives. I have managed to minimise (but not totally eliminate) these by narrowing and shifting the receiver audio bandwidth so that detections fall within the gaps between the interference lines.
Here are a couple of examples of meteor detections. This first graph shows a meteor trail lasting for between 0.5 and 1 second. Its very bright. There is a 2 second delay from the detection to the graph being produced this places the detection off the baseline of the graph and makes it much easier to read.

Not particularly exciting and note that there is no positional information so cannot be associated with a meteor shower or particular event. Nonetheless, it is still an indication of activity. An interference line can be seen just to the left of the captured event.
Typically, most trails are very short, so short that they would may not be detected by optical system. In this image, the event is much shorter than the previous example, lasting about 0.25 seconds:

I have circled the event for clarity. Note that the interference is much stronger in this snapshot.
This final capture shows a much stronger trail. The doppler shift is visible as the meteor slows down and burns up. It is so bright that it has triggered the AGC (Automatic Gain Control) which makes the background appear much darker.

If this was captured optically, it would have been very visible. However, it is a daytime capture and if it wasn't for the detection system used, it would have been totally missed.
Data Reduction
The data is collected and every night, just before midnight, a monthly graph is produced along with a data table for upload to RMOB.
The data graph looks like this with a summary of detections per hour, per day. This is the first graph produced, starting when the instrument went live on the 13th May.

This style of graph is known as a 'heat map'. The scale provides a hourly summary over the month, hours in the vertical axis, day number in the horizontal axis with each intersection showing the number of meteors captured during that hour.
Page 1 of 5


