Nearly all flight tracking sites offer automation scripts or raspbian images. Manual installation is not that hard at all (it involves quite a number of steps, but not difficult ones) but knowing the exact steps involved it makes a hell of a difference when it comes down to troubleshooting.
There are three main software layers involved.
- Hardware Driver.This replaces the original RTL driver that comes with raspbian distribution.
- DUMP1090. This is the ADS-B (Mode-S) decoding software that provides all core functionality. It scans the sky for airplanes and exposes them to 3rd party feeders.
- Feeders. They forward data from dump1090 to internet plane tracking sites. Currently there are 3 main plains trackers: FlightRadar24, FlightAware and PlaneFinder. Each site uses its own custom feeder. You may run all three of them simultaneously, there are no conflicts.
Formats, connections and ports
- Formats. The most popular formats used in the business of flight tracking are AVR, BaseStation and Beast.
- Connections. A feeder may also connect directly to a USB dongle. The use of dump1090 as an intermediate layer is required when multiple feeders require data from the same dongle. This will result in USB conflicts. dump1090 resolves those conflicts by exposing all available formats in different network ports. This way multiple feeder processes can coexist.
- Ports. This is where the majority of installation issues come from. Feeders have the capability of refeeding their data (except obviously the main tracker sites) locally by means of TCP ports for other apps (ex. VRS) to use. Feeders may also provide feedback to dump1090 (in case of mlat data) which implies that dump1090 should also have “listening” ports configured. Special care is needed that not more than one application (either dump1090 or a feeder) use the same port number.
DUMP1090 is using the following ports:
30001: AVR (raw) format in
30002: AVR (raw) format out
30003: BaseStation format out
30004: (30104) Beast format in
30005: Beast format out
Don’t get confused by the “in” and “out” above which refer to application level functionality. As far as TCP is concerned they are all “server-side” ports waiting for incoming connections. All the above ports should not be used by another application at the same time.
The flavor of dump1090 that will be used here is called dump1090-mutability (see relative section). This is mlat-aware from version 1.15dev onwards where it will accept mlat processed data on Beast-In port. At the moment only piaware, the client used by FlightAware, will refeed mlat data back to dump1090 for local display purposes. The port originally used was 30004 but in order to avoid piaware from feeding mlat data to a non mlat-aware dump1090 version it is now changed to 30104.