$ 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.
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?
[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.
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?
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?
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…
