Raspbian/Ubuntu packages for dump1090-mutability available

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.

I wouldn’t try working with this on the Pi uploading to FA, & PP. Looks like it’s time for another Pi :wink:

Didn’t Santa bring it or did you forget to order? Santa brought my #4 pi. Trouble is that you will always find a 24x7 task for the thing eventually…
/paul

It should coexist OK with piaware (I use it myself with piaware) - you actually don’t even need faup1090 in that case as it talks the FATSV protocol directly.

Can’t speak for PP feeds as I don’t use it, but I wouldn’t expect any problems with having it talking to ppup1090 (you’ll need to provide that yourself though)

A new project makes a good excuse for a new tool, right? :wink:

The repository is now properly signed and I put together a small config package that can be installed to configure it all. Top post updated with details.

Also released in the repo: MalcolmRobb dump1090: dump1090-mr v1.08.2302.14+1-3

still confused… how can I run this as a replacement for the FA version of dump1090? Does the executable remain named the same??? What changes in the startup? What potential conflict is there if I’m using autoupdate? What’s the overall advantage of this version over what’s in the FA version?

Should just be a case of installing the packages and halting any FA-installed version of dump1090 you’re running. piaware should notice the new dump1090 once it’s running.

Does the executable remain named the same???

It is installed as /usr/bin/dump1090-mutability to avoid conflicting with existing installs; you can install it alongside an existing dump1090 (although obviously you can only have one at a time running per dongle)

What changes in the startup?

Nothing much, the new daemon will get started if you configure it to be started; the package supplies a suitable init.d script for this, and when installing it will ask you whether it should configure it to automatically start.

What potential conflict is there if I’m using autoupdate?

I wouldn’t expect a conflict as it does not change anything involving existing installs of dump1090 or piaware, but by turning on autoupdate you have basically put your system maintenance in the hands of FlightAware, so you should really ask them what effects autoupdate will have on your system, not me.

What’s the overall advantage of this version over what’s in the FA version?

It plays better with existing systems that aren’t dedicated to running only the FA feeder; it has better configuration options; it has various new features listed in my original post; it’s more secure.

Plus I imagine it was enjoyable putting it together. :slight_smile: I’ll try install it sometime this week, after SD backup of course :wink:

Released dump1090-mutability v1.08.2302.14+1mu-7:

  • Notice if we lose the RTLSDR device, and try to reconnect when that happens.
    This lets you unplug/replug the RTLSDR without dump1090 exiting, and also lets dump1090 tolerate occasional USB glitches that make the dongle reset itself.

  • Fix some of the more glaring pthread bugs.

  • Center the webmap on the receiver location.

  • Mark config.js as a conffile, so user changes won’t get overwritten.

mu-6:

  • Add support for LOG_DECODED_MESSAGES option to log all messages (disables --quiet).

Full changelog

Question: does the LOG_DECODED_MESSAGES log each and every (repeat) instance of the ICAO hex as soon as it’s seen, or can it log an ICAO address and then not log that same icao for a length of time in order to save log space? Just curious. Or if anyone has a sample log output, that would probably give me an idea.

Thanks!

It just omits --quiet from the command line, so you will get a full decoded message output for every message received. (Yeah, it’ll get big pretty fast!)

Output looks something like this:

*8d400fde99447f90483c1634dc6d;
CRC: 000000 (ok)
SNR: 13.4 dB
Time: 1876301.00us (phase: 0)
DF 17: ADS-B message.
Capability : 5 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is airborne))
ICAO Address : 400fde
Extended Squitter Type: 19
Extended Squitter Sub : 1
Extended Squitter Name: Airborne Velocity
EW status : Valid
EW velocity : -126
NS status : Valid
NS velocity : -129
Vertical status : Valid
Vertical rate src : 0
Vertical rate : -896

*5d400fdeb062f9;
CRC: 000000 (ok)
SNR: 10.4 dB
Time: 2346007.00us (phase: 0)
DF 11: All Call Reply.
Capability : 5 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is airborne))
ICAO Address: 400fde
IID : II-00

*a000021685e00032700000b8a29c;
CRC: 400fde (ok)
SNR: 12.2 dB
Time: 2629454.00us (phase: 0)
DF 20: Comm-B, Altitude Reply.
Flight Status : Normal, Airborne
DR : 0
UM : 0
Altitude : 2350 feet
ICAO Address : 400fde
Comm-B BDS : 85

*a0000216ffb9f716bfec5c1d9b4f;
CRC: 400fde (ok)
SNR: 10.8 dB
Time: 2652837.50us (phase: 0)
DF 20: Comm-B, Altitude Reply.
Flight Status : Normal, Airborne
DR : 0
UM : 0
Altitude : 2350 feet
ICAO Address : 400fde
Comm-B BDS : ff

*8d400fde99447f90483c17cb2864;
CRC: 000000 (ok)
SNR: 12.4 dB
Time: 2936363.50us (phase: 0)
DF 17: ADS-B message.
Capability : 5 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is airborne))
ICAO Address : 400fde
Extended Squitter Type: 19
Extended Squitter Sub : 1
Extended Squitter Name: Airborne Velocity
EW status : Valid
EW velocity : -126
NS status : Valid
NS velocity : -129
Vertical status : Valid
Vertical rate src : 0
Vertical rate : -896

If you want to do anything smarter there, you’ll probably need to write something that reads the raw messages (or the port 30003 SBS output) and works with them itself.

Any suggestion on how to configure dump1090-mutability to use with fr24feed?