FlightAware Discussions

Raspbian/Ubuntu packages for dump1090-mutability available

I’ve been spending some time packaging my fork of dump1090 “the right way” and it’s got far enough that I am doing a wider release of the packages.

TL;DR

Raspbian: Set up the repository and signing key:



$ wget https://github.com/mutability/mutability-repo/releases/download/v0.1.0/mutability-repo_0.1.0_armhf.deb
$ sudo dpkg -i mutability-repo_0.1.0_armhf.deb


Ubuntu 14.04: Set up the PPA:



$ sudo add-apt-repository ppa:ojowett/dump1090


Both: Install and upgrade packages via apt-get:



$ sudo apt-get update && sudo apt-get install dump1090-mutability
$ sudo dpkg-reconfigure dump1090-mutability                           # for detailed configuration
$ sudo apt-get install lighttpd && sudo lighty-enable-mod dump1090    # if you want to use the external webserver integration
...
$ sudo apt-get update && sudo apt-get install dump1090-mutability     # to later upgrade to a newer version
                                                                      # "apt-get upgrade" will pick up newer versions too


Longer version:

This package is built from my fork of dump1090. This has various new (and somewhat experimental) features over stock dump1090:

  • 2.4MHz “oversampling” support

  • doesn’t run as root

  • supports FlightAware-TSV-format connections directly (same as the FlightAware version - no faup1090 needed)

  • can start from init.d, with detailed config via debconf or /etc/default/dump1090-mutability

  • can serve the virtual radar map via an external webserver (lighttpd integration included by default)

  • map view uses receiver lat/long given to dump1090 automatically

  • somewhat cleaned-up network code

  • tries to do things “the debian way” when it comes to config, package structure, etc

  • probably a bunch of other things I’ve forgotten…

For more detailed installation/configuration instructions please see the Github repo docs.

Current version is dump1090-mutability v1.14

Full changelog

Wow… awesome… :laughing:

Now… one question.

How does this affect piaware’s autoupdate (or update) in general?

Jim

And my response when I first saw your stats was a loud enough expletive to scare the dog…

Nice!

Awesome stats. Awesome contribution. Thank you.

It shouldn’t affect it, or be affected by it - in theory!

I want to use the command

:>| /var/log/dump1090-mutability.log 

to empty my log file. Successful operation of this command relies upon the log file being opened in append mode. Does the new version of dump1090 open its log file in append mode, please?

It does a shell append redirection (>>) so yes, it should be in append mode. The package ships a logrotate configuration that rotates weekly with copytruncate - you might want to adapt that?

I REALLY wish I had this kind of user community when I was doing app support! :laughing: :smiley:

[quote=“obj”]
I’ve been spending some time packaging my fork of dump1090 “the right way” and it’s got far enough that I am doing a wider release of the packages.

[li]The internal HTTP server is disabled. I recommend using an external webserver (see below). You can reconfigure to enable the internal one if you don’t want to use an external one.
[/quote][/li]This looks great and something I want to try when I get another receiver.

How can I turn off the internal web server in dump1090 if I’m running stock Piaware 1.18? I think it’s one of the prog args in fadump1090.sh. I would rather look at Virtual Radar Server and take some of the load off my Pi. Thanks.

–net-http-port 0 is what you’re after (same applies to other types of port - 0 disables).

Thank you. I’ll get to that as soon as I get out of the hospital. :cry:

My old dump1090 build (pre mutability) included files for compilation of ppup1090 to feed Plane Plotter data from port 30005 (Beast binary) of dump1090. The old /etc/init.d/dump1090.sh script is responsible for starting both dump1090 and ppup1090.

It seems to me that my new dump1090-mutability_1.08.2302.14.1mu-3_armhf.deb file does not include any provision for feeding to Plane Plotter. While I can organise for my old ppup1090 file to be started at Pi bootup from a script in /etc/init.d/, it would be nice and neat if the new mutability deb file also had an option to support feeding dump1090-mutability output to PlanePlotter. I could then completely remove all my old dump1090 files, rather than having to straddle between the two varieties of dump1090. My PlanePlotter ID is included in the file coaa.h and this would have to be included somehow.

I suspect I am not the only person who feeds PlanePlotter from dump1090. Are you interested in including PlanePlotter support in your new deb package, please?

TIA

This is a reasonable thing to ask for but it may take some time to do…

The planeplotter feeder requires linking against an armhf-only COAA provided binary object file that may only work against stock dump1090, and including info from a user specific header (your coaa.h) at build time. Both make it tricky to build a package that is suitable for all users and that I can test.

I’d probably have to reverse engineer the binary and reimplement to support it.

Maybe you can ask COAA to be more open about their integration?

This is GREAT!!!

One very small question:why


echo "deb http://repo.mutability.co.uk/raspbian wheezy rpi" >>/etc/apt/sources.list

and not e.g.


echo "deb http://repo.mutability.co.uk/raspbian wheezy rpi" >> /etc/apt/sources.list.d/mutability.list

-Paavo

Good suggestion. The “why” is because I wrote the install docs while writing the post, they are not necessarily perfect :wink:

(I should have some time to work on these packages again over the next week or so)

what’s the chances tagging when the signal was received accurately enough that it can be used for MLAT.

See here: http://discussions.flightaware.com/ads-b-flight-tracking-f21/flightfeeder-and-planeplotter-mlat-t19684.html

Stock (MalcolmRobb) dump1090 - and this version - already does this. Beast format output has a 12MHz clock value attached.

Note that the underlying sample clock is 2MHz or 2.4MHz, which then gets scaled up to give a 12MHz value. So you’re not getting the full precision that’s implied by a 12MHz clock. 2.4MHz mode also sneaks the detected phase information into the clock value, so there will be slightly better precision there.

Now you just need to build something to consume the data…

Released v1.08.2302.14+1mu-4. I’ve pushed that to my repository too so an apt-get upgrade should pick it up.