Analysing TCAS RA events in UK airspace using community-provided ADS-B data

As a member of OARC I've been running, over the past 2.5 years, an ADS-B aggregator. We wanted to see how much area of the UK (and later worldwide) we could cover with just OARC members on our Discord - although I did invite some friends later on. Right now, with HFDL included as well as ADS-B, we cover this area:

Quite impressive, really. We have roughly 85 people right now in various locations and feeding with different configurations. And over 2.5 years we've amassed a large amount of track data using readsb to compile it all together (and, of course, send on to the map tar1090 map system we use). Our current data archive is around 100 GB gzipped. Eek.

Of course, viewing aircraft on a map live and tracking what is going on in the world is one thing. I wanted to start using our data to actually look back at things and try to glean some useful information, maybe see some trends, and generally make it useful to keep all the data. But to do that you need ideas, some inspiration. Usually I am shit with this.

After the Washington DC mid-air collision between a military helicopter and a commercial aircraft I wanted to try to scan our data archive to see what the picture was like here in the UK. You may recall a system called TCAS exists to offer Traffic Advisories to aircraft, and also Resolution Advisories if needed - instructions sent to both aircraft on how to avoid each other. What you may NOT know is that the current TCAS state, and any instructions sent for avoidance, are sent down as part of the familiar ADS-B signal from each aircraft. Readsb can collate this info into a totally separate file, ready for analysis later.

With the help of ChatGPT - which sadly is how I do most of my coding work now that time is precious for me - I wrote a script to help parse these files, and in the following blog we're going to look at this data and see what we can find out. I also had a small idea that given how many times they appear in the logs off a quick check the helicopters of the Royal Family *may* have been the aircraft that conjuncts with others the most in the UK. Which would be very funny.

First, the script itself. It's very simple and is here. It simply loads in the aircraft.csv.gz file that most of the free and open sites use - based on Mictronics Aircraft Database - for airframe lookup, loads in a geojson file of FIR boundaries to analyse by area (I think outdated, but good enough), and then asks for a date start/end and a root folder location for the readsb data files. We run in globe_history mode, which stores all tracks forever and is what you need to do if you want a history on your local feeder longer than a day or so. You will need enough diskspace, of course.

RAs are counted from the moment they are first detected until a "Clear of Conflict" message is detected. The occurrence counts as a single occurrence for each individual aircraft - though there is handling for occurrences where only one of the aircraft is identified (which gets one added to its count). If neither aircraft can be identified then the event is logged as a single unknown occurrence. We don't really care much about those ones other than a quick count, and more feeders will eventually improve the situation.

If no Clear of Conflict message is received - because those frames were not received by the network, for example - the event times out after 60 seconds - a reasonable amount of time for a conflict to clear and for two pilots to have acted. Also, a first version of the script did not count more than one RA a day for one airframe, which was a critical fix to add. Multiple RAs VERY close together (say, 1 second apart) can be detected one after the other in this way for both aircraft, which is not always ideal. Technically those are separate triggers of an RA after a previous clear message. Human beings may consider this one conjunction event, however....

Of course, the feeder area will massively skew these results, but I have a fairly decent low level coverage in the UK - despite it being a little biased towards the south of England.

OK, enough chat, let's run the numbers in the entire dataset from 10th March 2023 to today, 21st September 2025. If the script is counting occurrences correctly there are 3008 instances logged where one or both airframes were identified. We'll start by looking for the top 10 aircraft represented:

This list has been annotated by myself to list owner info as these are not part of the downloadable Mictronics database, which is a shame. A mix of helicopters and small aircraft. No commercial aircraft appear in here at all, despite RAs occuring with them on the network as they change between cruise levels and that kind of thing. TCAS doesn't know that a pilot is going to level off somewhere, for example. A few German aircraft are in there, fed by a small group of stations. But the vast majority of the top 10 is from UK-based aircraft. Also JCB Excavators own helicopters for some reason. Let's use a bounding square box feature to specify a top left and bottom right coordinate to restrict our search:

A little better for our requirements. 1890 total occurrences in that box. And a slight shuffling of positions. And one more police aircraft and one private helicopter enters the list.

Another thing we can do is analyse the data points and see what area of airspace in the UK is responsible for generating the most of these alerts. The hotspot feature will analyse the data using DBSCAN - Density-Based Spatial Clustering of Applications with Noise - to try to cluster points together and spit out a geojson file which can be plotted on a map. This is a clustering algorithm that groups together points that are closely packed while marking points in sparse regions as outliers. It defines clusters based on density: a point becomes a “core point” if enough neighbors lie within a given radius (ε), and clusters grow by connecting core points and their neighbors. Unlike other methods, DBSCAN can find clusters of any shape and automatically identifies noise, without needing to specify the number of clusters in advance. And when we run this data through that system, with some tweaked variables to narrow down the cluster size, we get this:

This is an interesting result. You'll recall from earlier that Kent, Surrey and Sussex Air Ambulance was responsible for positions 2, 4 and 5 in the top 10 list. In this polygon is Redhill Aerodrome - coincidentally where their aircraft are based. The police aircraft has more individual conjunctions, possibly across a wider area, but as an organisation KSSAA's three choppers are responsible for pulling the most TCASey area in the UK over to their patch. It's also right next to Gatwick Airport, which won't help matters. And of course, as the most congested airspace in the UK it is no surprise that this polygon falls in the south of England, even factoring in the light feeder count in the north of England. It's all for the same reason really, and that is population density.

Of course, TCAS RAs are the system working. You can debate how the aircraft get into these situations as much as you want (and some RAs are reportable to the CAA) - but there is no doubt that this system saves lives and that when an alert is acted upon swiftly it results in a welcome outcome. This analysis is not meant to pour scorn on anyone, let alone the hardworking folk in the emergency services, but it is quite interesting to see it shown in this way.

Later advancements for the tools may include the ability to search by airline (using aircraft databases with owner/operator info), or maybe produce a toggleable hotspot layer for our aggregator. I may also add more analysis in the vertical perspective, restricting analysis to a range of altitudes to, for example, omit either high or low RAs as appropriate to the task. There is also a web side of this for the aggregator, allowing you to view events discreetly on a map. I want to add possibly a 3D playback of this view using CesiumJS to make events even clearer to look at: