antirez/dump1090

Dump1090 is a simple Mode S decoder for RTLSDR devices

Dump1090 README

Dump 1090 is a Mode S decoder specifically designed for RTLSDR devices.

The main features are:

• Robust decoding of weak messages, with mode1090 many users observed improved range compared to other popular decoders.
• Network support: TCP30003 stream (MSG5...), Raw packets, HTTP.
• Embedded HTTP server that displays the currently detected aircrafts on Google Map.
• Single bit errors correction using the 24 bit CRC.
• Ability to decode DF11, DF17 messages.
• Ability to decode DF formats like DF0, DF4, DF5, DF16, DF20 and DF21 where the checksum is xored with the ICAO address by brute forcing the checksum field using recently seen ICAO addresses.
• Decode raw IQ samples from file (using --ifile command line switch).
• Interactive command-line-interfae mode where aircrafts currently detected are shown as a list refreshing as more data arrives.
• CPR coordinates decoding and track calculation from velocity.
• TCP server streaming and receiving raw data to/from connected clients (using --net).

While from time to time I still add / fix stuff in my fork, I target minimalism of the implementation. However there is a much more feature complete fork available, developed by MalcolmRobb.

Installation

Type "make".

Normal usage

To capture traffic directly from your RTL device and show the captured traffic on standard output, just run the program without options at all:

./dump1090

To just output hexadecimal messages:

./dump1090 --raw

To run the program in interactive mode:

./dump1090 --interactive

To run the program in interactive mode, with networking support, and connect with your browser to http://localhost:8080 to see live traffic:

./dump1090 --interactive --net

In interactive mode it is possible to have a less information dense but more "arcade style" output, where the screen is refreshed every second displaying all the recently seen aircrafts with some additional information such as altitude and flight number, extracted from the received Mode S packets.

Using files as source of data

To decode data from file, use:

./dump1090 --ifile /path/to/binfile

The binary file should be created using rtl_sdr like this (or with any other program that is able to output 8-bit unsigned IQ samples at 2Mhz sample rate).

rtl_sdr -f 1090000000 -s 2000000 -g 50 output.bin

In the example rtl_sdr a gain of 50 is used, simply you should use the highest gain availabe for your tuner. This is not needed when calling Dump1090 itself as it is able to select the highest gain supported automatically.

It is possible to feed the program with data via standard input using the --ifile option with "-" as argument.

Additional options

Dump1090 can be called with other command line options to set a different gain, frequency, and so forth. For a list of options use:

./dump1090 --help

Everything is not documented here should be obvious, and for most users calling it without arguments at all is the best thing to do.

Reliability

By default Dump1090 tries to fix single bit errors using the checksum. Basically the program will try to flip every bit of the message and check if the checksum of the resulting message matches.

This is indeed able to fix errors and works reliably in my experience, however if you are interested in very reliable data I suggest to use the --no-fix command line switch in order to disable error fixing.

Performances and sensibility of detection

In my limited experience Dump1090 was able to decode a big number of messages even in conditions where I encountered problems using other programs, however no formal test was performed so I can't really claim that this program is better or worse compared to other similar programs.

If you can capture traffic that Dump1090 is not able to decode properly, drop me an email with a download link. I may try to improve the detection during my free time (this is just an hobby project).

Network server features

By enabling the networking support with --net Dump1090 starts listening for clients connections on port 30002 and 30001 (you can change both the ports if you want, see --help output).

Port 30002

Connected clients are served with data ASAP as they arrive from the device (or from file if --ifile is used) in the raw format similar to the following:

*8D451E8B99019699C00B0A81F36E;

Every entry is separated by a simple newline (LF character, hex 0x0A).

Port 30001

Port 30001 is the raw input port, and can be used to feed Dump1090 with data in the same format as specified above, with hex messages starting with a * and ending with a ; character.

So for instance if there is another remote Dump1090 instance collecting data it is possible to sum the output to a local Dump1090 instance doing something like this:

nc remote-dump1090.example.net 30002 | nc localhost 30001

It is important to note that what is received via port 30001 is also broadcasted to clients listening to port 30002.

In general everything received from port 30001 is handled exactly like the normal traffic from RTL devices or from file when --ifile is used.

It is possible to use Dump1090 just as an hub using --ifile with /dev/zero as argument as in the following example:

./dump1090 --net-only

Or alternatively to see what's happening on the screen:

./dump1090 --net-only --interactive

Then you can feed it from different data sources from the internet.

Port 30003

Connected clients are served with messages in SBS1 (BaseStation) format, similar to:

MSG,4,,,738065,,,,,,,,420,179,,,0,,0,0,0,0
MSG,3,,,738065,,,,,,,35000,,,34.81609,34.07810,,,0,0,0,0

This can be used to feed data to various sharing sites without the need to use another decoder.

Antenna

Mode S messages are transmitted in the 1090 Mhz frequency. If you have a decent antenna you'll be able to pick up signals from aircrafts pretty far from your position, especially if you are outdoor and in a position with a good sky view.

You can easily build a very cheap antenna following the istructions at:

http://antirez.com/news/46

With this trivial antenna I was able to pick up signals of aircrafts 200+ Km away from me.

If you are interested in a more serious antenna check the following resources:

• http://gnuradio.org/data/grcon11/06-foster-adsb.pdf
• http://www.lll.lu/~edward/edward/adsb/antenna/ADSBantenna.html
• http://modesbeast.com/pix/adsb-ant-drawing.gif

Aggressive mode

With --aggressive it is possible to activate the aggressive mode that is a modified version of the Mode S packet detection and decoding. THe aggresive mode uses more CPU usually (especially if there are many planes sending DF17 packets), but can detect a few more messages.

The algorithm in aggressive mode is modified in the following ways:

• Up to two demodulation errors are tolerated (adjacent entires in the magnitude vector with the same eight). Normally only messages without errors are checked.
• It tries to fix DF17 messages trying every two bits combination.

The use of aggressive mdoe is only advised in places where there is low traffic in order to have a chance to capture some more messages.

Debug mode

The Debug mode is a visual help to improve the detection algorithm or to understand why the program is not working for a given input.

In this mode messages are displayed in an ASCII-art style graphical representation, where the individial magnitude bars sampled at 2Mhz are displayed.

An index shows the sample number, where 0 is the sample where the first Mode S peak was found. Some additional background noise is also added before the first peak to provide some context.

To enable debug mode and check what combinations of packets you can log, use mode1090 --help to obtain a list of available debug flags.

Debug mode includes an optional javascript output that is used to visualize packets using a web browser, you can use the file debug.html under the 'tools' directory to load the generated frames.js file.

How this program works?

The code is very documented and written in order to be easy to understand. For the diligent programmer with a Mode S specification on his hands it should be trivial to understand how it works.

The algorithms I used were obtained basically looking at many messages as displayed using a trow-away SDL program, and trying to model the algorithm based on how the messages look graphically.

How to test the program?

If you have an RTLSDR device and you happen to be in an area where there are aircrafts flying over your head, just run the program and check for signals.

However if you don't have an RTLSDR device, or if in your area the presence of aircrafts is very limited, you may want to try the sample file distributed with the Dump1090 distribution under the "testfiles" directory.

Just run it like this:

./dump1090 --ifile testfiles/modes1.bin

What is --strip mode?

It is just a simple filter that will get raw IQ 8 bit samples in input and will output a file missing all the parts of the file where I and Q are lower than the specified for more than 32 samples.

Use it like this:

cat big.bin | ./dump1090 --snip 25 > small.bin

I used it in order to create a small test file to include inside this program source code distribution.

Contributing

Dump1090 was written during some free time during xmas 2012, it is an hobby project so I'll be able to address issues and improve it only during free time, however you are incouraged to send pull requests in order to improve the program. A good starting point can be the TODO list included in the source distribution.

Credits

Dump1090 was written by Salvatore Sanfilippo [email protected] and is released under the BSD three clause license.

dump1090's Issues

Map not show in Chromium sometimes

Maps not show in Chromium sometimes, Firefox is always OK. Chromium version 31.0.1650.63 Ubuntu 12.04 (31.0.1650.63-0ubuntu0.12.04.1~20131204.1)

Build system suggestions

-pkg-config ... gets run every time (twice), please use $(shell pkg-config ...) to evaluate and store the result.

-Don't mess with the systems CFLAGS, esp. do not overwrite values.
Use += instead of =.

• Respect LDFLAGS, add $(LDFLAGS) before $(LIBS)

Awesome app! This is so going to Gentoo/Linux main repo!

Ettus USRP support?

Is it possible to operate dump1090 with ettus usrp devices?

regards.

Incorrect extraction of vert_rate_sign - always shows as climb

was
1080 mm->vert_rate_source = (msg[8]&0x10) >> 4;
1081 mm->vert_rate_sign = (msg[8]&0x8) >> 5;
1082 mm->vert_rate = ((msg[8]&7) << 6) | ((msg[9]&0xfc) >> 2);

should be
1080 mm->vert_rate_source = (msg[8]&0x10) >> 4;
1081 mm->vert_rate_sign = (msg[8]&0x8) >> 3;
1082 mm->vert_rate = ((msg[8]&7) << 6) | ((msg[9]&0xfc) >> 2);

Bit 3 is incorrectly shifted right 5 places (resulting in always 0) rather than 3 places (0 or 1).

cheers John.

Raw-data Client

Hi,

actually ADSB# includes an Hub which allows to build your own network like FR24. To use this hub it is necessary to activley connect your client to this hub. At the moment I do this using dump1090 and socat to forward the data from your pretty good software to the hub. It would realy be a nice feature if there would be the possibility to do this within dump1090. You "just" need to establish a connection to a given host and port and send the raw data to it. Of course some kind of automatic reconnection after a drop (maybe due to some DSL reconnect) would be nice ;)

Maybe you can think about ;)

Best regards,
Johannes

Error cb transfer on Atheros AR9330

Hello, i have a problem to run error free MalcomRob dump1090 on

TL-WR703N.
I like MalcomRobb fork of dump1090 for the better HTTP output

but, in my configuration, is instable.

HARDWARE TL-WR703N v1
Software OpenWrt Attitude Adjustment 12.09
Cpu Atheros AR9330 rev 1

TOP report Mem 5228K free .... CPU average 34%

=============== Error =======================

MalcomRobb DUMP1090 Ver : 1.07.0610.13

Run average 3-5 minute then ERROR "cb transfer status: 1"

./dump1090 --net

*5d34150de2d1d0;
CRC: 00002c (ok)
DF 11: All Call Reply.
Capability : 5 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is

airborne))
ICAO Address: 34150d
IID : SI-28

cb transfer status: 1, canceling...

./dump1090 --net --raw

*a8000315807dad34600ce1241122;
*a000171710010080e60000a40219;
cb transfer status: 1, canceling...
*a000171710010080e60000a40219;

I also cross compiloed the first MalcomRob
version d3662bb
( Implemented Beast Binary output) and i have the same error.

Antirez last master (acecc6d)

Work flawless, i run it for 48 hours without problems.

After a lot of version crosscompiling and test the problem seem
introduced by the first version of MalcomRobb.
There is other report of this error? there is a solutions?

I am not a programmer... No one would add a better HTTP output

to Antirez dump1090?

Thanks
Roberto Zinelli

Minor change for my own convenience

Hi, So that I don't have to go rummaging around in the main code, I've changed one line and added one line in gmap.html.

The standard initial zoom of 5 was far too small for me. I needed a zoom of 11 initially as I live under a flight path into & out of LGW.

After line 42 I added:

InitZoom=11;

and at line 156 I changed the code to:

zoom: InitZoom,

Now the CenterLat, CenterLon and InitZoom initialisations are conveniently near the start of the code.

I also changed CenterLat/Lon to my house so the browser starts up showing traffic in my immediate vicinity.

Great bit of software. Many thanks.

Chris

Feature Request : Redis support :-)

any chance of adding an output to a local Redis table mode ? - that contained rows not unlike the interactive mode view - ie values get filled in as more data arrives, keyed off hex_id, and auto deleting if not seen...

go on... you know you want to... if you haven't already :-)

Bad use of LDFLAGS in commit 36cec38

See comments on 36cec38 for details

--- dump1090-9999/Makefile
+++ dump1090-9999/Makefile
@@ -1,5 +1,5 @@
 CFLAGS?=-O2 -g -Wall -W `pkg-config --cflags librtlsdr`
-LDFLAGS?=`pkg-config --libs librtlsdr` -lpthread -lm
+LDLIBS+=$(shell pkg-config --libs librtlsdr) -lpthread -lm
 CC?=gcc
 PROGNAME=dump1090

@@ -9,7 +9,7 @@
        $(CC) $(CFLAGS) -c $<

 dump1090: dump1090.o anet.o
-       $(CC) -g -o dump1090 dump1090.o anet.o $(LDFLAGS)
+       $(CC) -g -o dump1090 dump1090.o anet.o $(LDFLAGS) $(LDLIBS)

 clean:
        rm -f *.o dump1090```

Integration with gpsd

It would be great to take a position from gpsd (if available and running), to auto-center the map display.

dump1090.c line 298. Can we save memory of magnitude by 2?

Hi,

In dump1090.c line 298:
"
(Modes.magnitude = malloc(Modes.data_len*2)) == NULL) {
"
Why there is "times 2"? Two bytes (I&Q) in Modes.data generates one item in magnitude, and one magnitude item (uint16_t) cost two bytes. So I think magnitude needs exactly the same memory size as data.

Or do I miss sth?

Interactive shows flights not visible on the net HTML page

I use this commandline:
./dump1090 --metric --enable-agc --net --net-http-port 8080 --interactive --aggressive
(need to cd to dir otherwise html file will not be found ... see other bug report here)

There are many flights with known position and track. (see below interactive screenshot)
But it shows currently 0 planes on the HTTP GUI.
Why?!?

Hex Flight Altitude Speed Lat Lon Track Messages Seen .

2000f7 0 0 0.000 0.000 0 1 15 sec
3c646b CFG6AM 11560 833 0.000 0.000 320 64 11 sec
4404d5 0 0 0.000 0.000 0 1 41 sec
8963ce 11270 0 0.000 0.000 0 3 55 sec
3c6490 DLH5AC 10029 842 48.210 15.945 91 612 0 sec
3c6593 DLH8NW 11270 861 47.556 15.618 114 394 0 sec
471ea7 10966 814 0.000 0.000 309 8 1 sec
506c07 9747 0 0.000 0.000 0 1147 0 sec
3c6561 DLH639 10357 807 47.837 15.710 291 1638 4 sec
4a8188 SVF820 0 0 0.000 0.000 0 565 0 sec
3c544c DLH8CR 10661 872 47.598 15.862 108 674 22 sec
405ee1 BAW697 3762 655 48.252 16.126 334 2073 0 sec
506c1a 9443 0 0.000 0.000 0 1299 1 sec
451e84 VIM371 11567 829 48.245 15.700 294 2574 25 sec

Have some ideas, may fork

I just started using D1090 and I have a bunch of ideas I want to implement. I was thinking about forking the Malcolm Robb fork but I just looked and there are a lot of forks out there already. Not sure if I should start another one. Below are my ideas and a mockup.

1. When a new aircraft is first mapped, a sound will be played.
2. Mapped aircraft will have an info window that displays flight, equipment, fare, plan, altitude.
3. The right frame will be converted to an accordion and default to closed.
4. Aircraft that do not transmit lat/long will be appear as UFOs and include a signal level meter.
5. SQL Lite will be installed and track all mapped aircraft.
6. Data points to save will be ICAO, flight, equipment, date last seen, on-time rating.
7. There will be a settings menu to set these options.
8. Aircraft markers will default to always have tail lines.
9. If an aircraft is above a set altitude, two tail lines representing contrails will appear.
10. The contrails will become a single line once an aircraft is below a set altitude.
11. The contrails should merge together/apart as the aircraft gains/loses altitude.
12. Once an aircraft lands, the color of the icon should change to green.
13. The marker icon should change based on the type of equipment.
14. A centralized DB will be created to manage N Number mapping.
15. If an aircraft is screaming overhead, the flight and altitude will be announced.
16. Mac OS and/or Festival will be used for speech.
17. The on-time rating will be defined as: 90% ontime = A, 80% B, 70% C, 60% D, below F.
18. Colors of the lines will change based on altitude.
19. If some info is not available, e.g. equipment, it will not be shown on the info window.
20. The marker should scale in size when you zoom.

Added --quiet and --ppm

I added a couple of simple changes that:

1. allow the ppm_error variable to be set
2. suppress all output to stdout when the app is used as a daemon

Created a pull request at yuvadm's request.

Feature Request: Bounding box to drop anything outside of it

I took the output from the past 4-5 days and shoved it into a google fusion table so I can see roughly my coverage before and after an antenna move. I found that I got lat/log sometimes on the other side of the world from where I am at. A simple command line option to add a bounding box so if outside of the box, consider the data packet invalid.

See following link for pretty coverage map of before the antenna move.
https://www.google.com/fusiontables/embedviz?viz=MAP&q=select+col6+from+1qFXBYtP15niuh6TaZAW9er_aQt1DTXPzDKmmZu4&h=false&lat=35.254066939198324&lng=-80.96867563472358&z=9&t=1&l=col6&y=2&tmplt=3

Crashes with message "cb transfer status: 1, canceling..."

I've been running dump1090 for a few days on a Raspberry Pi, first down in my garden (not a super reception ~50km, but good enough to start testing). Now that I've moved it up on the roof (same hardware/antenna), I'm getting a lot of crashes with the message "cb transfer status: 1, canceling..." (I've also seen a few time the number 5, but much less).

I run dump 1090 from source (retrieved ~ a week ago, i.e. acecc6d) from it's own folder by running
$ ./dump1090 --interactive --net

It looks like if I don't request the web page, it will stay a bit longer (2-3 hours?), but will eventually crash. If I request the web page directly, the crash can happen in a few minutes.

I have a suspicion it might be due to more signals being retrieved from my roof, and maybe my Raspberry Pi then struggles to decode it all? The weird part is that top doesn't return horrible values (~30% CPU and 2% memory usage):

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2676 pi 20 0 14808 4664 828 R 30.2 2.0 0:10.70 dump1090

EDIT: Info about my hardware:
Raspberry Pi Model B first generation (256mb RAM) running Raspbian with self-compiled Linux kernel 3.8.13+ (to have driver support directly from the Kernel for my DVB stick)
Connected using a wireless stick, computer is 2 stairs above the router, not great wifi reception.
Terratec Cinergy TStick RC (rev 3), contains E4000 tuner and RealTek RTL2832U. When starting Dump1090 this is displayed:
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001 (currently selected)
Found Elonics E4000 tuner

I'm currently using the antenna supplied with the DVB stick, I've made a dipole as shown on your blog but am not seeing major differences (probably some implementation fault on my side ;) )

I'm also pushing my data back up to FlightRadar24 using their precompiled binary for ARM, dynamically linked. Not sure if that could have an impact?

Would you have any idea what status 1 or 5 for "cb transfer" points to?

Possible feature: Zeroconf support?

Hi,

I've been working a bit with zeroconf/bonjour before and it's quite neat to just be able to start your networked applications without any need for configuring clients. This would add dependencies to either avahi libs or other 3rd party libs, would this be an interresting feature? Basically it would be an extension of the --net flag to broadcast the available services. If it would, then I could take a look at it and try to get something up for review, but I do understand if you just want to keep the minimalist approach.

Br,
Ola

Distribution Request

I am a developer for the ArchAssault project, we are working on distributing this project to our users. However we need a license file, I see that its a BSD 3 license, but do you have a modified version of it.

Actually we are trying to pull in this fork https://github.com/MalcolmRobb/dump1090 but he inherits your license. I also can't open an issue on his fork of the project. Let me know thanks.

Cannot load server in an alias folder

Scenario:
I have the adsb web page loaded in an aliased virtual directory on my server (example.com/adsb/) which acts as a proxy to the http port of dump1090.

Expected Result:
The web page should load as normal and display the airplanes.

Actual Result:
The javascript in gmap.html tries to load "/data.json" instead of "data.json" which would end up being "adsb/json.data" and go through the virtual directory properly.

Fix:
I have confirmed that removing the leading "/" from "/data.json" resolves the problem and I have not observed any adverse effects.

A current work-around is to also proxy "/data.json" to the dump1090 port, but this adds extra complexity and the possibility of name clashes (especially being a generic filename).

Exit when encountering an usb disconnect "cb transfer status: 1, canceling..."

A combination of my cat and a loose usb con leads to usb dis- and reconnects every few weeks.
I'd like to run the program in a loop, but it doesn't terminate or reconnect after such disuptions.
Just exiting to the command line with a non-zero return code would be great.
Thanks.

Planes won't be deleted from map after ttl

Hi,

Hi antirez,

problem is still there. I'm starting dump1090 with:

!/bin/sh

dump1090 --enable-agc --gain 49 --no-fix --device-index 0 --net | socat -u - TCP4:xx.xx.xx.xx:xxxxx &
exit 0

You can see the planes painted map on

incaseyoureat.dyndns.org:8080

GM is full of planes, now. I don't know why maps painted by planes if I start dump1090 like that....
and leave shell planes freezes. so, it's still there.

Wrong west "Lon" value ?

Hi,

Aprox. 29.4248 / -15.9644 coordinates are showed like :

---

44a838 JAF6GJ 8666 842 29.177 351.009 16 1277 1 sec

Thanks for you great work!

for OSX ?

hi!

Is there a chance to get a optimized dump1090 version or a howto for compiling on mac osx ?

that would be awesome :)

Support lower sampling rate

Hello,
I wanted to lower the CPU usage on Raspbbery Pi by using lower sampling rate in rtlsdr, but it seems all the decoding is hardcoded for 2 MHz and dump1090 did not detect any aircraft with lower sample rate.

If I understand the sample rate correctly, it means how much data around the tuned frequency we see at once. So it should be 1090 MHz +/- 2 MHz. I guess Mode S data are much narrower, so we shouldn't need to process the whole 2 MHz. Or is there any other option how to decrease the CPU usage?

Error compiling - cannot find -lusb....

If you try to compile on a 64 bit system it throws some errors. Fixed by adding -m32 to the gcc args in the makefile.

Long / Lat not decoding

I get a lot of messages like this:

*8fd0ac0f8bbbde4fce6107fb1fa6;
CRC: fb1fa6 (ok)
Single bit error fixed, bit 27173
DF 17: ADS-B message.
Capability : 7 (Level 7 ???)
ICAO Address : d0ac0f
Extended Squitter Type: 17
Extended Squitter Sub : 3
Extended Squitter Name: Airborne Position (Baro Altitude)
F flag : odd
T flag : UTC
Altitude : 36525 feet
Latitude : 75751 (not decoded)
Longitude: 24839 (not decoded)
*8e62a10f953b573f93581d2215d8;
CRC: 2215d8 (ok)
Single bit error fixed, bit 18203
DF 17: ADS-B message.
Capability : 6 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7))
ICAO Address : 62a10f
Extended Squitter Type: 18
Extended Squitter Sub : 5
Extended Squitter Name: Airborne Position (Baro Altitude)
F flag : odd
T flag : non-UTC
Altitude : 10725 feet
Latitude : 106441 (not decoded)
Longitude: 88093 (not decoded)

*8cc89bfc913a9c43470ffecf3fe4;
CRC: cf3fe4 (ok)
Single bit error fixed, bit 22080
DF 17: ADS-B message.
Capability : 4 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is on ground))
ICAO Address : c89bfc
Extended Squitter Type: 18
Extended Squitter Sub : 1
Extended Squitter Name: Airborne Position (Baro Altitude)
F flag : odd
T flag : UTC
Altitude : 0 feet
Latitude : 8611 (not decoded)
Longitude: 69630 (not decoded)

Is this normal for the long/lat to not decode?

Position decoding error

I'm acutally using version 1.04.0105.13 from MacolmRobb but didn't find a possibility to post on hier repository.
I have several wrong positions in the output on port 30003, I can't prove but I expect the same errors in the "normal" output. It seems that this is the first position from an aircraft. The latitude seems to be correct but the longitude for all wrong positions in 1.0°.
I found this error using SRV30003 from jetvision to plot the max. distance for my receiver.

No altitude on some aircraft, but it exists

Occasionally I see some aircraft not reporting alt, seem to be older aircraft, however, a quick test of MalcolmRobbs fork, and it reports it! quick kills' and restarts between the two confirm Antirez's version not decoding it, but Malcolm's does, its also been over several aircraft, tested over several days, so not sure where Malcolms changes get this but obviously I report it as a bug since the "upstream" parent/master/actual code devs version, does not.

I execute both binaries identical : dump1090 --net --interactive --aggressive

Example, aircraft VH-LEM

Antirez

DF 17: ADS-B message.
Capability : 5 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is on airborne))
ICAO Address : 7c384c
Extended Squitter Type: 4
Extended Squitter Sub : 1
Extended Squitter Name: Aircraft Identification and Category
Aircraft Type : Aircraft Type A
Identification : LEM

DF 17: ADS-B message.
Capability : 5 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is on airborne))
ICAO Address : 7c384c
Extended Squitter Type: 11
Extended Squitter Sub : 0
Extended Squitter Name: Airborne Position (Baro Altitude)
F flag : even
T flag : non-UTC
Altitude : 0 feet
Latitude : 77568 (not decoded)
Longitude: 70581 (not decoded)

DF 0: Short Air-Air Surveillance.
Altitude : 0 feet
ICAO Address : 7c384c

MalcolmRobb

DF 17: ADS-B message.
Capability : 5 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is airborne))
ICAO Address : 7c384c
Extended Squitter Type: 4
Extended Squitter Sub : 1
Extended Squitter Name: Aircraft Identification and Category
Aircraft Type : A1
Identification : LEM

DF 17: ADS-B message.
Capability : 5 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is airborne))
ICAO Address : 7c384c
Extended Squitter Type: 11
Extended Squitter Sub : 0
Extended Squitter Name: Airborne Position (Baro Altitude)
F flag : even
T flag : non-UTC
Altitude : 10500 feet
Latitude : -26.449219
Longitude: 152.823970

DF 0: Short Air-Air Surveillance.
VS : Airborne
CC : 0
SL : 0
Altitude : 10500 feet
ICAO Address : 7c384c

Wrong "Track" value

Just noticed that dump1090 in interactive mode displayed impossible value for the "Track" field:

Hex    Flight   Altitude  Speed   Lat       Lon       Track  Messages Seen   .
--------------------------------------------------------------------------------
424941 AFL2550  9747      757     56.647    23.314    265   87        41 sec
14f109 SDM324   10676     0       56.877    23.679    823400808   212       313 sec
4249db AFL2346  10357     785     56.877    22.887    257   475       2084 sec

I'm using the latest version: b6907f4
Launched with: ./dump1090 --interactive --interactive-ttl 3000 --metric

Feature Request: Aircraft type

Add identification of aircraft type.

BaseStation format

Hello,

very popular format of data is BaseStation, eg. FR24 app use this format of data, but dump1090 have only AVR :(

Is there a chance to support BS format by dump1090?

There is source of similar funcionality:
http://diseqc.org.ua/projects/hard/adsb/adsbox-20120427.tar.gz

Best Regards
Radek

Feature request - Signal Strength

I am a student pilot in the US.Thanks for developing dump1090.
Out here there is a lot of Mode C traffic, which means that they do not transmit their GPS co-ordinates. So I see a lot of airplanes but I do not know where they are. I was wondering if you could add a signal strength parameter?

This way one could approximate the distance of the aircraft based on the signal strength. There are commercial products which work in a similar manner (eg: zaon mrx).

Thank you.

Make Error

gcc -O2 -g -Wall -W pkg-config --cflags librtlsdr -c dump1090.c
Package librtlsdr was not found in the pkg-config search path.
Perhaps you should add the directory containing `librtlsdr.pc'
to the PKG_CONFIG_PATH environment variable
No package 'librtlsdr' found
dump1090.c:46:21: fatal error: rtl-sdr.h: No such file or directory
compilation terminated.
make: *** [dump1090.o] Error 1

I have RTL_SDR installed

Add support for compact position reporting (CPR)

• Allow user to set lat/lng receiving position
• Show calculated aircraft position in real time report
• Add position column in interactive display

CPR calculations can be referenced from https://github.com/bistromath/gr-air-modes/blob/master/python/cpr.py

Airport dump

I would appreciate if someone could record a raw dump with airport (surface) traffic, including takeoffs and landings. Maybe 30m is ok.

Crashing when passed a large cookie

When I was working on the WebGUI I enabled a few things to save positioning of elements via cookies. I noted that when the http server in dump1090 gets a cookie it tends to do a full on crash.

I only replicated this under @MalcombRobb 's branch for now. I have not tried the root of all this to see if it exists there.

Support non-RTL raw data clients

It would be great to be able to support non RTL devices like the ModeS Beast through a USB serial port.

Longitude Out

Have been running dump1090 here in Adelaide Australia.
Plane position lat/long places them about 100km to the east - lat seems about right long is out.
Checked out src with git clone https://github.com/antirez/dump1090.git file dates are Feb 25 2013 ... build no?
CLI dump1090 run up:
ross@eeepc:/dump1090$ ./dump1090 --net --aggressive --metric --raw > raw_dump_v1_2_mar_2013
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001 (currently selected)
Found Elonics E4000 tuner
Max available gain is: 42.00
Setting gain to: 42.00
Exact sample rate is: 2000000.052982 Hz
Gain reported by device: 42.00
^C
ross@eeepc:/dump1090$

--raw file here
http://www.air-stream.org/files/raw_dump_v2_2_mar_2013.txt

Release version numbers

Would it be possible to have release numbers, this would make it easier for packaging Dump1090 into Debian for instance.
It can be as simple as tagging the git repo with a version number... Thanks!

Longitude Out (similar as issue #13)

Hi! I'm running the latest version (already up-to-date) and am still seeing a similar issue as reported in issue #13. I'm from Buenos Aires, Argentina, South America, and the planes are positioned about 200km to the west. The planes are shown to be at Lon -60 where they should be at -58. I'm attaching the raw output, any ideas? Thanks!

Lat/Long for southern hemisphere

Hi antirez, amazing work you're doing with dump1090.

I'm having an issue, I live near Buenos Aires, Argentina, my coordinates are -34.2 (lat) -58.3 (long) but dump1090 in interactive mode shows all the planes with 325 (lat) and 71 (long). Why is that? is there any way to convert those values to W/E N/S ? Last, in spite that the web page shows planes being tracked I can't see any on screen, could this be related to the lat/long issue?.

Best regards and please keep improving dump1090.
LU

PS: it would be nice to have a web forum for dump1090

Document how to build with MacPorts

It is not clear how to build the project when using MacPorts for dependencies. I will investigate for myself, but it would be nice to have this documented or improve the Makefile.

So far I have done:

port install rtl-sdr

though when I run make I get:

Ghostwalker-Zeta:dump1090 ajmas-isu$ make
gcc -O2 -g -Wall -W `pkg-config --cflags librtlsdr` -c dump1090.c
/bin/sh: pkg-config: command not found
dump1090.c:46:10: fatal error: 'rtl-sdr.h' file not found
#include "rtl-sdr.h"
         ^
1 error generated.
make: *** [dump1090.o] Error 1```

Add LICENSE file with BSD license text

I'd eventually like to package Dump1090 for Debian, for easy "apt-get install" installation, but I can't figure out under which license you've developed Dump1090. Could you please specify if this is under one of the OSI-approved licenses? Adding a LICENSE file to your source would be ideal!

Link to flight information

I like being able to quickly look up information about the flight number. To do that I added this to gmail.html where the flight number gets populated (LN91)

html += '<b><a href="https://www.google.com/search?q='+p.flight+'">'+p.flight+'</a></b><br>';

Anirez vs Marco Robb

I know that this is the origional version of dump1090, but the github user malcomrobb seems to have made many more commits. Which is more up to date and feature laden, and which would I fork?

data limit 131072

When I use curl of centos to request data.json,if data over 131072 byte,this request will be not complete and timeout,how can I fix this problem?

best wishes!

Add an option to display SkyVector charts as the base map

Either replace or add a button to switch between Google Maps and SkyVector charts (http://skyvector.com) for the base map.

Couple of buglets for you to think about

I've spent the weekend porting this to run under Winfows (Visual C++ 6). Whilst I realise the target is Linux, the following issues would help maintain portability.

1. The return pointer from malloc is (void*). The M$ Compiler complains if you don't explicitly cast this to the type of the receiving pointer variable. Therefore, I'd request that the return values from all malloc's are type cast.

2. The long long variable type isn't supported in the M$ compiler. I'd request that you change all long long to uint64_t, You're already using uint8_t,, uint16_t, and uint32_t, so typedefing uint64_t shouldn't be that difficult?

3. Your Modes.buffer is allocated to be Modes.data_len bytes in size. Your Modes.magnitude is allocated to be (Modes.data_len*2) bytes in size. However, the magnitude buffer doesn't need to be *2, because although the values in it are uint16_t in size, they are calculated from I/Q byte pairs in the Modes.buffer. Therefore it needs 2 bytes from the Modes.buffer in order to generate one uint16_t in the magnitude buffer. Hence the declarations can be the same size. Given the size of thse buffers, you're wasting 258Kb of memory.

Now some tweaks I;ve made.

4. Your Modes.maglut buffer is 129x129 uint16_t (33282) bytes in size. You then kludge up the I/Q values in computeMagnitudeVector() by subtracting 127 and then negating the value if it is negative before indexing in into the Modes.maglut buffer to get the vector magnitude. This works ok, but, on slower processors, this is additional work that could be avoided by having a larger Modes.magnitude buffer.

So I/d suggest increasing the Modes.magnitude buffer to be 256x256 .uint16_t in size (131072 bytes) . You can then just pickup the 16 bit I/Q value, directly index into the Modes.magnitude buffer, and get the 16 bit magnitude.

The extra size of the maglut buffer is more than compensated for by memory saved in 3) above. There is additional code to initialise the maglut buffer in the first place, but this is only tun once during initialisation, so doesn't really affect performance.

5. in your maglut initialisation, you're multiplying the sqrt(i_i+q_q) by 360. This is presumably to scale the results up by 1.4 - i.e. root 2? Root 2 is actually 1.414213, so isn't 362 a better value to multiply by?

6. You are copying raw I/Q data supplied by the RTLSDR callback into Modes.data. Then in the other thread you're translating this Modes.data into the Modes.magnitude buffer. You can get rid of the Modes.data buffer all together if instead of just memcpy'ing the I/Q data from the RTLSDR callback buffer, you translate it on the fly straight into the Modes.magnitude buffer.

This will slow down the rtlsdrCallback() thread, but since access to the Modes.data buffer is protected by mutex anyway, the overall performance won't be affected since you won't need to call computeMagnitudeVector() in the main thread. Infact, since you're saving a memcpy(), overall performance will be quicker.

Cheers
Malcolm

--metric variable on net page

when you put --metric variable in a string like this: "./dump1090 --net --aggressive --net-http-port 8080 --metric --gain 50"
On the web page doesn't result metrics condition

gmap.html not found, if current dir is not dump1090's dir

If I launch dump1090 from my homedir (~/sw/dump1090/dump1090 --net), it cannot load the "gmap.html" file and displays message: "Error opening HTML file: No such file or directory", when the address is accessed by web browser.
"/data.json" is accessible though.
If I change the current dir to dump1090's one and then launch it, it works as expected.