request: decouple decoder from guide

[wiedehopf]

https://github.com/llopisdon/skies-adsb/blob/main/docs/INSTALL-GUIDE.md

The guide seems to couple dump1090 into your setup procedure. It would be much nicer if you could separate that so people already running a decoder like readsb (https://github.com/wiedehopf/adsb-scripts/wiki/Automatic-installation-for-readsb) or dump1090-fa, don't install dump1090-mutability making 2 decoders fight over the SDR.

Also i'm not sure why you wouldn't want a systemd service to start dump1090-mutability.

[llopisdon]

hi @wiedehopf thanks for the feedback.

I will update the docs to include instructions for setting up the app with existing dump1090 installations. The app just needs any SBS1 BaseStation formatted data source on a network.

In the meantime if you wish to run the app with your existing setup you can follow the instructions here:

https://github.com/llopisdon/skies-adsb/issues/2

As for your comment about starting the dump1090-mutability service at boot. I'm not 100% sure what to do about this. The RPI Raspbian dump1090-mutability package is running dump1090-mutability as the user dump1090. This user does not appear to have the right permissions to connect USB devices out of the box.

I wanted to make the setup as simple as possible so I run dump1090-mutability in the background as the default pi user in the skies-adsb.service to get around this issue.

Do you have any recommendations on how to fix this?

Thanks

[wiedehopf]

Oh i see. Well i'd just NOT use dump1090-mutability :) My readsb would have the added benefits that MLAT results being pushed into readsb will be emitted via SBS.

But i get that you'd rather not link to some bash script someone else made (or build a package you don't know about).

In regards to permissions:

sudo adduser dump1090 plugdev

This should fix the permissions. I'm pretty sure the dump1090-mutability package does that ... maybe not :)

It will need a reboot after installing librtlsdr0 package though as it adds udev rules for SDRs so they are usable by the plugdev group.

I'm not planning to run the app myself but i forsee other people wanting to run it on existing setups and as i'm rather active helping people fix their installs / feeds to adsbexchange, i'd rather avoid some work :)

[llopisdon]

hi @wiedehopf

Adding dump1090 to the plugdev group fixed the issue. Not sure why the dump1090-mutability package is not doing this by default. I will add this to the setup instructions.

Regarding readsb. I'm pretty new to this stuff. Does readsb also output SBS data to port 30003?

Thanks

[wiedehopf]

dump1090-mutability was forked and is being maintained by the same author as dump1090-fa 3 years ago dump1090-fa was forked into readsb by Mictronics. I'm maintaining a readsb fork that's diverged from the original readsb fork.

But all that software is basically doing the same job and we keep the ports as somewhat of a standard.

Now if you feed adsbexchange or flightaware and take part in their MLAT system, you'll get back MLAT positions, those are by default pushed into 30004 or 30104 via the beast protocol. My version is currently the only one which will provide those MLAT positions on port 30003. Though you could get MLAT results as SBS separately via the various MLAT clients if you run give the correct command line options, some of them mgiht already be listening.

[llopisdon]

hi @wiedehopf

I have updated the install guide with a section on how to run the app using another decoder. I have also included instructions for how to run the app on a non-RPI localhost.

see:

https://github.com/llopisdon/skies-adsb/blob/dump1090-refactor/docs/RPI-INSTALL-GUIDE.md#step-4c-optional---use-existing-ads-b-decoder--customize-rpi-setupsh-script

https://github.com/llopisdon/skies-adsb/blob/main/docs/LOCALHOST-INSTALL-GUIDE.md