Dump1090 for Windows

Gisle Vanem

New Member
Hello folks. I just got approved on this PlaneFinder forum after 2 days; These background checks takes time; Inshallah.

Anyway, I just ported the original Dump1090 by Salvatore Sanfilippo to Windows.
  • added better network support.
  • use WindowsConsole calls instead of ESC codes.
  • dropped anet.c in favour of the Mongoose HTTP-server.
  • plans to use Web-sockets for the Web-interface.
But I'm a n00b when it comes to JavaScript. So if anybody would help with this, my
project is at Github here: https://github.com/gvanem/Dump1090
This is GREAT! Thank you

Tested on Windows10. Works great.

- Downloaded .zip from Github: https://github.com/gvanem/Dump1090/archive/refs/heads/main.zip
- Unzipped downloaded folder
- In unzipped folder, created blank file "run.bat" and added following code in it.
- Double-clicked "run.bat" to run the dump1090.exe

dump1090.exe --interactive --net --net-ro-port 30002 --net-sbs-port 30003





Usage: dump1090.exe [options]
  --aggressive             More CPU for more messages (two bits fixes, ...).
  --debug <flags>          Debug mode (verbose), see README for details.
  --device-index <index>   Select RTL device (default: 0).
  --freq <hz>              Set frequency (default: 1090 Mhz).
  --gain <db>              Set gain (default: AUTO)
  --infile <filename>      Read data from file (use '-' for stdin).
  --interactive            Interactive mode refreshing data on screen.
  --interactive-rows <num> Max number of rows in interactive mode (default: 15).
  --interactive-ttl <sec>  Remove from list if idle for <sec> (default: 60).
  --loop                   With --infile, read the same file in a loop.
  --metric                 Use metric units (meters, km/h, ...).
  --net                    Enable networking.
  --net-only               Enable just networking, no RTL device or file used.
  --net-ro-port <port>     TCP listening port for raw output (default: 30002).
  --net-ri-port <port>     TCP listening port for raw input (default: 30001).
  --net-http-port <port>   HTTP server port (default: 8080).
  --net-sbs-port <port>    TCP listening port for BaseStation format output (default: 30003).
  --no-fix                 Disable single-bits error correction using CRC.
  --no-crc-check           Disable messages with broken CRC (discouraged).
  --onlyaddr               Show only ICAO addresses (testing purposes).
  --rate <hz>              Set sample-rate (default: 2MS/s).
  --raw                    Show only messages with raw hex values.
  --strip <level>          Strip IQ file removing samples below level.
  -h, --help               Show this help.

  Debug mode flags: E = Log frames decoded with errors.
                    D = Log frames decoded with zero errors.
                    c = Log frames with bad CRC.
                    C = Log frames with good CRC.
                    p = Log frames with bad preamble.
                    n = Log network debugging info.
                    N = Log a bit more than network events.
                    j = Log frames to frames.js, loadable by debug.html.
                    G = Log general debugging info.
Last edited:
> dump1090.exe --interactive --net --net-ro-port 30002 --net-sbs-port 30003

Thanks. That's good news considering I've not tested the --net-sbs-port argument at all.
SBS? Is that's what's called the Beast protocol?
sbs is BaseStation format. Each line starts with "MSG"

Beast I think is NOT available in Antirez (Salvatore Sanfilippo) version, but I am not sure about it.

I am however sure that it is available in Malcolm Rob /mutability/flightaware versions (default port 30005)
--net-bo-port <port>  TCP listening port for beast output (default: 30005).

Its output by dump1090 versions MalcolmRobb/mutability/flightaware is like below:

Beast output from port 30005.png
Last edited:
I will suggest you fork dump1090-mutability or dump1090-fa and build dump1090.exe from it's source code.
These two use planes like planefinder map.
Antirez & MalcolmRob use embedded web-server, which you have replaced by Mongoose HTTP-server.
The mutability & flightaware forks use external HTTP-server lighttpd.
As you have experience, this should not be a problem to replace external web server lighttpd by embedded Mongoose HTTP-server.

Last edited:
Just a FYI (and a late response). I've updated my Dump1090 program with a simple Curses interface.
And running it inside Windows Terminal with a nice background image, it looks pretty nice IMHO:

Dump1090 in WT
Good day, after some extensive research I came to realise that the sprut miniadsb receiver plus AVR adsbPIC decoder cannot be used in conjunction with dump1090 for Windows. This is because dump1090 receives and processes digital samples of the actual baseband signal received from the RTLSDR, i.e. it cannot receive & process the raw adsb frames.

Please confirm this is indeed the case? Is there no way that a component of dump1090 could be used to process raw adsb frames received from the sprut AVR adsbPIC decoder?

In order to process & display such frames, I must use sprut's adsbscope or Planeplotter? Any other such processing & display applications that can be used?

Thank you.
> to the laptop PC at 115kbps

This implies a COM-port or a COM-to-USB thing. No?
Dump1090 does not support that currently. But possible.
> to the laptop PC at 115kbps

This implies a COM-port or a COM-to-USB thing. No?
Dump1090 does not support that currently. But possible.
Yes COM port via USB. dump1090 processes "8-bit unsigned IQ samples at 2 MHz sample rate" received from the RTLSDR.

The sprut miniadsb receiver and adsbPIC decoder also receives and processes adsb transmissions, but instead sends ASCII strings via USB COM port to PC at 115kbps. The PC uses adsbScope or Planeplotter to map the data.

Thank you Gisle.
I wrote a small TCP socket Python script on the Raspberry Pi. The script connects to the sprut adsbPIC decoder's USB COM port, sends a command to the PIC to enable transmission of all received frames, and pushes all received ADS-B frames via Ethernet to a PC running Virtual Radar Server. Works pretty well, except that the push mechanism sometimes disconnects, so I'll rather have the Python script run a TCP server to which VRS can connect to source the frames.