Flighttracker

From RevSpace
Revision as of 19:26, 16 September 2022 by Jelly (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
Project Flighttracker
Flighttracker1.png
Revplane tracker
Status In progress
Contact jelly
Last Update 2022-09-16

RevFlight tracker

With a simple RTL-SDR it's possible to receive flight "beacons" which a commercial aircraft emits. There is software which in combination with an DVB-t receiver can show the planes flying in the area. We want to put an antenna on the roof of revspace and recieve flight information.

Antenna

For receiveing ADS-B we build our own coaxial collinear antenna using this guide.

Hardware

Our antenna is connected to a simple RTL-SDR usb stick which hooked up to a nanopi neo running armbian. The nanopi neo is housed in a waterproof FiBox and powered by PoE using a Poe splitter to 5v usb micro (this also provides ethernet to the pi).

Setup

On the nanopi neo we run rtl_tcp so we can have multiple clients connect to our nanopi and access the ADS-B data.

 $ apt install -y rtl-sdr
 $ rtl_tcp -a 0.0.0.0 -f 1090000000 -s 2400000

Note that the frequency and sample rate are important to get right otherwise dump1090 is unable to receive data for details see this and this webpage.

The default rtl_tcp port is 1234, to receive ADS-B data on a client:

 $ nc 11.22.33.44 1234 | dump1090 --ifile -

Running

  • Run ./dump1090 --interactive --net
  • Open http://localhost:8080/ in your browser to see an interactive google map

Monitor

The plan is to create a sonar like display of the current airplanes. dump1090 can dump the raw msg (? hex encoded). There is a Python library which might make it easier to decode the messages from dump1090

Images

alt text
alt text

ADS-B multilateration

This idea is about determining position of aircraft that don't transmit GPS position themselves.

Many commercial aircraft transmit ADS-B/MODE-S signals containing all kinds of interesting information: aircraft id, altitude, flight number, speed, heading and position. This way you can plot the trajectory of aircraft on a map and get an interesting view of the air traffic around. The arrival of cheap software-defined-radios like the rtl-sdr made it possible for everyone to receive these signals.

Typically, small aircraft like single-engine air planes and helicopters do not transmit position information, only the aircraft id, altitude and sometimes flight number. Websites like flightradar24 receive information about these small aircraft from many different receivers, and can infer the position by multilateration. Multilateration means that the position can be calculated from the relative delay that the ADS-B signal arrived at the different receiver stations (the radio signal moves at the speed of light!). The required accurate time synchronization needed for this can be calculated in a smart way from the ADS-B signals themselves.

Stuff needed for this to work:

  • receiver stations at diverse locations are needed, so you get a good 'constellation' receiving aircraft signals from many different angles
  • each receiver station should be able to time-stamp the ADS-B signals it receives. It doesn't really matter if it is accurate in an absolute sense, just needs a certain time resolution.
    • so we need a common convention on how/what to time-stamp ADS-B, take something that is present in each message, e.g. the exact instant that the first bit of the ICAO address is transmitted
  • about time resolution: radio signals move at the speed of light; one sample at 2 Mbps sample rate is 0.5 microsecond, representing a distance of 150m.
  • a central server receives all the ADS-B signals from the multiple receiver stations
    • it matches up the same message from different receivers, knows where each receiver is, and performs the multilateration calculation
    • it continually monitors the time offset of each receiver, by comparing timestamps from ADS-B message that DO contain GPS information
    • since rtl-sdr receivers drift like crazy (up to 100 ppm), the server probably also needs to estimate the drift rate of each receiver. At 100ppm, a one second old timestamp could already be off by 100 us, or 30km!
  • some kind of network protocol to get all the ADS-B data from each receiver to the central server

Seems like someone already did this, see https://github.com/mutability in the repos dump1090, mlat-server and mlat-client.