Local ADS-B receiver is not running

What am I over looking? I have to gone to other similar threads and have not yet been able to resolve the issue. I am feeding FR24 and ADS-BEXCHANGE for nearly 2 years prior to adding fligghtaware with no issues. I am really at a roadblock on this one. I can use the remote web interface, but my not my local web interface.

pi@ADSB-PI:~ $ piaware-status
PiAware master process (piaware) is running with pid 5478.
PiAware ADS-B client (faup1090) is running with pid 5510.
PiAware ADS-B UAT client (faup978) is not running (disabled by configuration settings)
PiAware mlat client (fa-mlat-client) is running with pid 5507.
Local ADS-B receiver (dump1090) is not running.

readsb (pid 516) is listening for ES connections on port 30005.
faup1090 is connected to the ADS-B receiver.
piaware is connected to FlightAware.

dump1090 is producing data on localhost:30005.

readssb takes away the local web interface “removes other decoders (dump1090-mutability / dump1090-fa … local skyaware interface won’t be available anymore, use /tar1090 which comes with this installation)”

As @craigtrex600 said, the web interface came with dump1090fa.

If this is replaced with readsb, you will need to have a different web interface.
Following the automated installation provided by @wiedehopf via his github repository, you are having a different web interface already installed with tar1090.

Can be usually reached via http://<Raspberry-IP>/tar1090

If it’s not installed because you have readsb set up individually, you can install tar1090 seperately:

1 Like

I am curious to know what is advantage of readsb over dump1090-fa?

If it is because people like tar1090, then tar1090 works with dump1090-fa also.

1 Like

What might be the advantage of using Google Chrome over Mozilla Firefox? :wink:

Similar question. I think it’s simply a personal preference…

That is what I thought.

I had dump1090-fa installed on all my RPis. Later, on top of that I installed tar1090 without uninstalling anything existing. I get both interfaces, i.e. tar1090 as well as skyaware.

I am still learning this stuff,as far as working with linux, but the github link referenced looked to be fairly comprehensive so I went that route. I have been feeding FR24 and ADSBX for almost 2 years and FA for a couple of days now, so I had the prior setup first. I am just trying feed multiple sites with least issues is all. I have followed all the instructions on the FA website. I have multiple pi3b+'s here, so if you have a more practical solution for feeding multiple flight radars, I am definitely all ears. I had a friend help me set the first one up that kept crashing weekly, so I rebuilt a different one, because I am not a fan of unreliable hardware.

1 Like

There is just no need for the local dump1090-fa interface.
In other words, remove dump1090-fa, piaware will feed just fine.

1 Like

There is some functionality you can enable by using readsb like /tar1090/?replay and /tar1090/?heatmap
that needs changing the config because writing to disk by default is not that nice with sd-cards.

tar1090 is … mostly made for readsb nowadays.
readsb has some different behaviours in regards to CPR decoding and some things.
better or worse is probably a very fine line for those differences.

It’ll use less data transfer viewing the /tar1090 page if it’s backed by readsb because it uses binary. But that’s really irrelevant for the local receiver.

The wind speed / wind direction / TAT / OAT is calculated by readsb instead of tar1090 if you use readsb.
That is more accurate as readsb knows when the data is updated.

I’ve quite recently added --gain=auto but if you prefer that over the dump1090-fa auto gain is a whole different question.
One thing you might like which is a somewhat recent addition is that you can change the gain while readsb is running:

echo 43.9 > /run/readsb/setGain
echo auto-verbose > /run/readsb/setGain

Regardless the user asking here has readsb running and it seems like a bad reason to switch to dump1090-fa to get the “local FA webinterface” which isn’t particularly useful?

3 Likes

Thank you for detailed explanation. I was not aware of these differences.

By the way it is not only readsb which is without web interface. RadarBox24 supplied dump1090-rb also does not have a web interface. I once configured rbfeeder to
network_mode=false
which started dump1090-rb. I then installed tar1090, but it failed because it could not find aircraft.json file in normal places as dump1090-rb uses /dev/shm/dump1090 folder by default.

However I could find a workaround for it.

But it’s not without webinterface, the usual install script pulls in tar1090.

3 Likes

Ok, thank you kindly for the reply.

I am working on getting some other changes made to improve coverage, but my setup is running really good as is. The broadcast engineer in me knows it can do much better even though my longest path on ADSBX 257 NMI and FR24 is 224 nmi. I am currently running the FA 1090 omni antenna, the FA pro plus dongle, a 1090 only BP filter, and a 10m section of what I assume is LMR-195 feedline on a RPI 3B+. antenna is outside on the garage about 15’ in the air. I do have a nice length of lmr-600 with N connectors to go on it and a better 1090 cavity that offers 75 db outside of band rejection with less than 0.5db loss to help lower my noise into the SDR. It is a work in progress, but will definely improve well with my current plans and the great out of band rejection I am hoping will allow to pull in much weaker ADSB packets and be able to decode them.

Again, thank you for the reply that addresses my concern at hand. I am glad to know that I do not have an issue at all and that everything is actually working as it should.