Flighttracker: Difference between revisions
No edit summary |
No edit summary |
||
(5 intermediate revisions by 2 users not shown) | |||
Line 9: | Line 9: | ||
== RevFlight tracker == | == 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. | 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 [https://balarad.net/ guide]. | |||
== Hardware == | |||
Our antenna is connected to a simple RTL-SDR usb stick which hooked up to a [https://www.armbian.com/nanopi-neo/ 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 == | == 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 [https://github.com/antirez/dump1090/issues/87 this] and [https://discussions.flightaware.com/t/decoding-iq-data-from-rtl-tcp-remotely/19573/8 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 == | == Running == | ||
Line 28: | Line 39: | ||
== Monitor == | == Monitor == | ||
The plan is to create a sonar like display of the current airplanes. dump1090 | 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 [https://github.com/junzis/pyModeS library] | ||
which might make it easier to decode the messages from dump1090 | which might make it easier to decode the messages from dump1090 | ||
Line 35: | Line 46: | ||
[[File:flighttracker1.png|200px|thumb|left|alt text]] | [[File:flighttracker1.png|200px|thumb|left|alt text]] | ||
[[File:flighttracker2.png|200px|thumb|left|alt text]] | [[File:flighttracker2.png|200px|thumb|left|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. |
Latest revision as of 19:26, 16 September 2022
Project Flighttracker | |
---|---|
![]() | |
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
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.