Announcement

**Oblivian** · 2015-12-20, 18:01

Needs to be configured to use avrt cp on 30002. Ensure dump1090 is running first. Fixed. Fa detects your running config

Sent from my XT1092 using Tapatalk

**af4ex** · 2015-12-20, 20:47

Thanks for the reply, but I'm not sure what "avrt cp" is. How do I use that?

Are you saying that I must run dump1090 standalone, before starting fr24feed and piaware? How is that done automatically from bootup? What arguments need to be provided?

Currently each feeder has installed and runs its own dump1090 (fr24: /usr/lib/fr24/dump1090 fa:/usr/bin/dump1090). Will they both see the dump1090 already running? Do they both use the same dump1090 arguments, such as "--mlat" and "--net"?

Also, I installed fr24feeder using the recommended "apt-get" method. I'm not using the Debian dpkg installer. Will that make any difference?

Thanks,
John/af4ex

EDIT, 4pm:
Just noticed that FR24 and FA are using different versions of dump1090 (1.10.3010.14 and 1.2-3, resp.). And FA has an additional option, "--forward-mlat", that FR24 doesn't have. So, which one should be shared?

Actually, I think it would be much simpler and safer just to let both feeders run their own stuff. Why can't we do that?

**af4ex** · 2015-12-20, 23:00

@me
> ...not sure what "avrt cp" is. How do I use that?

Just realized you meant "avr (tcp)". So I stopped both feeders, changed fr24 to 'avr', host=30002 and restarted fr24 first then piaware.

Still no joy.
2015-12-20 17:41:49 | [reader][i][0]Connecting to Generic receiver via (avr-tcp://30002)
2015-12-20 17:41:49 | [reader][e][0]Could not connect to avr-tcp://30002
2015-12-20 17:41:54 | [feed][n]ping 1
2015-12-20 17:41:54 | [reader][i][0]Connecting to Generic receiver via (avr-tcp://30002)
2015-12-20 17:41:54 | [reader][e][0]Could not connect to avr-tcp://30002

It's worse than before. Now piaware is not running either. Rebooting didn't help. :-|

Any suggestions on how to proceed from here?

John/af4ex

**Oblivian** · 2015-12-21, 05:53

Theres a couple of things involved here.

FR24 is designed to be standalone, and only those who have done otherwise on forums are likely to advise how to work with other products, since they only support their own stand-alone test beds. So I doubt you will find a sticky as there are too many variants of hardware/software releases and user accounts involved to cover it all.

However with little to no linux knowledge I followed the advanced step-by-step similar to this to get it going. Which focuses on Dump1090-MU (there is also a standalone guide on the D1090 forums) http://discussions.flightaware.com/a...le-t19619.html

Essentially the FR24 bundle (new one if you updated it correctly) has a standard D1090-MU now. Piaware is aware of what is installed beforehand, FR24 not so much.

Default FR24 will fire up D1090-mu when it starts, and stop it when it quits. This is the child threads you see. If you at any time reconfigure D1090 or update it outside the package you run risk of it running as a service, and FR24 trying to re-run (similar to above I suspect) unless setup in 3 stages checking as you go.

My advice. Remove FR24 package.
Install Dump1090 standalone for functionality - get Dump1090-MU running as a service.
sudo dump1090-mutability status (or start/stop)
Hack on Pi-aware - it should find dump1090-MU running.
If you have completed the dump1090 setup properly there will be output on 30002, configure the fr24feed.ini to use this (or leave it configured as it is now)

Its a matter of being able to use the service (running in background + startup) commands vs 1-time run and seeing their status to work out your layering and what to change in the apps to stop multi-process running

IE
sudo service fr24feed start - start as service (if configured to launch dump1090 it will.. and fail if D1090 is a service running)
Sudo fr24feed start - run in current process and display messages (crashes on quit but may leave dump1090 running!!!)
sudo service dump1090-mutability status/start/stop (start/stop as service or on startup)
sudo piaware-status - does that.
sudo service piaware start/stop/restart

**af4ex** · 2015-12-21, 13:19

Thanks for the detailed info. Yes, there are many variant systems running out there, which makes it difficult to assert "solutions". But I'm just running the 'plain-vanilla' RPI/R820T/dump1090-mr, which is probably the most common variant. That should be an easy "baseline" for setting up a multi-app system, all sharing a single dump1090 receiver.

I was able to get piaware running again, but I had to use a standalone dump1090 (malcolm-robb). Previously it used its own dump1090, but now that doesn't start up anymore after I fiddled with the FR24 config. Strange.

Also, I now realize you really can't have more than one dump1090 running, with the canonical port settings, because ports are always "global" to each computer system. So, only one program on a system can open a port for output. (But multiple programs can read ports).

I like the piaware dump1090, because its html output plots the Mode-S aircraft in blue, using the coordinates calculated from MLAT. The plain dump1090-mr also plots the Mode-S birds, but all in the same color, which is confusing to say the least.

From what you said it's likely that FR24 won't play nicely with FA dump1090, so looks like I'll have to uninstall it. A shame because it has some nice features, e.g. being able to click on an aircraft and see which "radar" is tracking it. FA doesn't seem to have that ability yet. But, with its builtin ranking system, it provides a lot more feedback to users who want to improve their systems.

Thanks,
John/af4ex

EDIT 8:30AM:
For those who might want to duplicate my results, be aware that FA has changed the default MLAT input ("beast" format) port from 30004 to 30104, so you will have to add an extra parameter to older versions of dump1090 invocation: "--net-bi-port 30104". My dump1090 is invoked by the service in /etc/init.d/dump1090.sh, yours might be in a different script.

If you don't make this change you'll get a ton of errors on the failed MLAT readings, which are reported in FA's curiously 'hidden' logfile: /tmp/piaware.out

**af4ex** · 2015-12-21, 14:05

So, in closing my comments here, I still think FR24 should publish a single and authoritative thread or document on how to make FR24 play nicely with FA etc.

That also means it should emulate PIAWARE, which on startup checks to see if there is any dump1090 running and always use that (because TCP/IP receivers are always global resources and really can't be "local" to each app).

Here's what the PIAWARE man page says on this subject:
"On startup piaware attempts to connect to port 10001 to obtain the filtered, coalesced ADS-B messages. If the machine is running the FlightAware-modified version of dump1090 (https://github.com/flightaware/dump1090_mr) then it will obtain those messages directly.

If the site is not running FA-modified dump1090 or is running a different ADS-B provider program such as modesmixer then piaware will start a helper program called faup1090 to translate between beast format and FlightAware format."

Otherwise, the current requirement to have FR24 always start first with its own receivers seems to portray a rather unfriendly attitude towards the rest of the growing ads-b DIY users in the world.

Announcement

Need sticky thread on running FR24FEED and PIAWARE together

Need sticky thread on running FR24FEED and PIAWARE together

Comment

Comment

Comment

Comment

Comment

Comment