Tracking ADB-S probes directly from your Kubernetes cluster

By


In the last 3 months, i started feeding to Flightradar24 ADB-S probes since i always wanted and was curious how radio positioning-based tracking works, in this small post i will try to write down some considerations and hands-on notes for those who want to experiment with in the same way or set up

Before we start here is some theory, so what’s ADB-S?

ADB-S stands for Automatic Dependent Surveillance and in short for non-technical people could be reduced as:

  • Each Plane, Boat or any ground vehicle that has ADB-S transmitters sends specific messages
  • Those messages do contain useful data such as position, heading, altitude, radio callsign, etc..
  • Most aircraft in Europe nowadays require to send out ADB-S messages (I think there are exemptions but for obvious reasons e.g. military, police, etc..)

Ok, cool now that we know what is and what is used for how can we track those messages?

Let’s start with the ingredients before cooking:

  • RTL-SDR / USB dongle or any radio receiver able to catch 1090MHz frequency
  • An antenna long enough to catch the same wave lenght of 1090Mhz so 27cm or a half 13.5cm or even a quarter of wave length 6.75cm
  • A Computer / RPi / NUC with a Kubernetes cluster (also single node labs work out fine)
  • Internet connectivity (optional if you want to feed the data to public sites)

Before starting there is a prerequisite that all the deployments i have made are based on a Kubernetes cluster thus i will provide references to that specific use case

Connecting and testing the dongle

Before starting you may try to test out your SDR setup with SDR++ or RTL1090 on a Windows desktop for example so you are sure that:

  1. Your hardware works

  2. You have planes flying over you

The best place to start setting up your hardware can be this quickstart guide from the RTL-SDR.com blog:

After you have launched RTL1090 you should be able to see ADB-S messages as soon as plans are transmitting over you, in case you are keeping the antenna indoor, your range may be limited

Try to keep your antenna close to windows or better outside if you have a coaxial cable but not too long

Installing the components in your K8s cluster

Since we started testing the SDR directly from a client using the standard clients now we can start connecting it to our Computer / RPi / NUC, in my specific case i connected the dongle to my NUC and placed the dipole telescopic antenna set to 6.3cm (or the minimum closest size)

The antenna ideally should be placed on the roof with a complete line of sight (no trees , buildings covering too much) for optimum range coverage

Speaking of antennas there are many types and ways to build your custom one the most favorite is the following:

Personally speaking i didn’t have the time yet to explore and building my antenna as with the stock one i can get enough data so far, i think might be a nice experiment to see how the different types of antenna affect range without changing the setup settings

Now back to the software part, the components required to be installed are the following:

  1. dump1090

This component is needed to collect all the ADB-S messages received by your SDR

Technically speaking it’s a deployment containing the dump1090-fa (FlightAware fork) software made for RPi or dockerized deployments

This component has been packaged into this helm chart and to use it can be referenced as follows:

resource "helm_release" "dump1090" {
  name       = "dump1090"
  repository = "<https://charts.sa.mi.it/>"
  chart      = "dump1090"
  version    = "0.2.7"
  force_update = "true"
  
  set {
    name = "dump1090exporter.enabled"
    value = "true"
  }
  set {
    name = "ingress.enabled"
    value = "true"
  }

  set {
    name = "ingress.hostname"
    value = "dump1090.ingress.local"

  }

}
  1. dump1090_exporter

This component is needed to export metrics and let the data be available for Prometheus scraping jobs

 You can find the prepared docker image here

To enable the exporter you can use the existing helm chart seen before and just enable the option:


  set {
    name = "dump1090exporter.enabled"
    value = "true"
  }

An example of potential dashboards can be the following one:



So potential metrics available with the exporter are the following ones (just a few not the complete list):

dump1090_recent_aircraft_max_range
dump1090_recent_aircraft_max_range_by_direction
dump1090_recent_aircraft_max_range_by_direction
dump1090_recent_aircraft_with_multilateration
dump1090_recent_aircraft_with_position
dump1090_stats_cpr_airborne
dump1090_stats_local_peak_signal_strength_dbFS
dump1090_stats_local_samples_dropped
dump1090_stats_local_samples_processed
  1. fr24feeder

This component acts as a feeder for the ADS-B messages you've tracked, sending them to Flightradar24. To obtain a Flightradar24 API key, you'll need to sign up manually. In my case, I used the internal CLI after running the Docker image:

  • fr24feed --signup

This process will prompt you to provide your Flightradar24 account email for association.

Deployment is straightforward using the Helm chart with default values. Just replace the placeholder with the FR24 key you obtained during registration.

 

Here below you can find the interface (accessible via the ingress of the fr24feeder) which can be usefult for some troubleshooting and checking logs details:


 

 

How it works?

Basically, after you generate an API key by yourself using their software and once it is registered and associated with your FR24 account you can start tracking planes and feeding them into FR24

Stats will be available later under your account or by searching in the global stats if you agreed to share your receiver stats:

What are the benefits?

Flightradar24 offers a Business subscription plan for receivers that contribute data. This plan allows you to view valuable statistics about your receiver's performance.





Conclusion

This experiment has been a great way to learn more about ADS-B tracking and how the systems function even without any kind of eletronics, signals background

The SDR space offers a vast array of possibilities, and exploring all of them could easily consume entire days and months

Here are just a few examples:

  • Satellite transmissions (e.g., downloading publicly available satellite images from NOAA)
  • Radio-based communications (e.g., reverse engineering how rolling codes work in doorbells, garage door openers, and cars)
  • GPS and radio-related tracking
  • 5G/4G network exploration


Comments

Post a Comment