but i’m wondering - why does flightaware not have ONE single post/thread where we can find ALL basic documentation e.g.
list of versions, changes and possible performance improvements
directories and users they install to
configuration- options, ways, files, defaults etc.
sending our data for free (hardware, installation, maintenance, location, energy costs) in my opinion better documentation should be provided.
it is super inefficient that anybody has to search in so many places to find (or not) these basic information.
@FA Staff: http://flightaware.com/adsb/piaware/about is a great overview but needs updating with the new default port of 30104. You might also add another (optional) data flow: output from fa-mlat-client to other software like VRS etc. May I suggest a default listening port of 30105 for synthetic mlat positions?
mgunther - i don’t think ‘this is a great overview’ - it’s just one tiny piece of the puzzle and moreover it’s outdated.
and it’s outdated because anything is here and there and nowhere.
i’m not a geocacher!
Part of the issue here is that the standard, most common install is the sdcard install; this is the “out of the box” solution.
As soon as you start doing other things, though, such as feeding to other software or using a different dump1090 or installing onto an existing Raspbian system or running on Ubuntu or whatever, the assumption is that you basically know what you’re doing. There are enough different “other things” and enough different ways to do it that documenting it all is, at best, a lot of work, and at worst an exercise in futility. More documentation is good but there is a line somewhere.
If you just want to feed data and the details aren’t so important, stick with the sdcard image.
If you want to improve the docs, then specific suggestions would be good.
the fa forum itself and the fa interface for ads-b sites are supergood and best in industry!
in my opinion over the next time the raspi2 running raspian will be the way more than 90% sites will go.
so - having two options there - plugandplay via complete sd-image or self install of dump1090 and piaware - is a perfect offer.
as i wrote before - ONE single post/thread on top where we can find ALL basic documentation would make things way easier.
specific suggestions:
list of versions, changes and possible performance improvements
directories and users they install to
configuration- options, ways, files, defaults etc.
i know that documentation is extremely boring - but on the other hand extremely helpful. so there should be one person at least from staff doing this about 1 full day per week.
This is documented on github, I can link there (in fact, I did in the 2.1-3 post)
and possible performance improvements
Out of scope, really.
directories and users they install to
This is part of the package metadata and you can access it via dpkg, like any other Debian package; I’m not sure that we should be documenting Debian package management stuff when it is well documented by Debian itself.
configuration- options, ways, files, defaults etc.
This is documented on github, I can link there.
The border here is probably that it makes sense to document the piaware feeder, but it doesn’t really make sense to document dump1090 etc as shipped on the sdcard in much detail as that is usually the first part to be replaced. So the docs are going to be along the lines of “Here’s how piaware works, here are the config options for piaware-config, you will need to provide a data feed on port 30005 via some other mechanism not provided by piaware”.
can’t be your real belief. if you buy a new car - open the manual and all pages there are in confused order. and then on most pages you just find the message 'please contact bosch about the abs, please contact bose about radio, please contact zf about gear shifting …
what i’m talking about is ONE CENTRAL POINT where all documentation can be found (or in-depth is linked from) and is up-to-date
The one thing I’ve been thinking about doing is sitting down and drawing a mud-map of the various data flows (directions) and port numbers - mainly so I can get my own head around how not to feed FA generated MLAT to FR Thats the cause of the majority of issues when people try to multi-feed and being able to see where the data flow is / isn’t / should be going would make fault finding a touch easier.
Whats the old saying: a picture is worth 1000 words - for me, that’s certainly the case !!
Thanks for all your help this week too, obj , much appreciated.
I guess we’ll just have to agree to disagree. The only way I can see to have a single central up to date set of documentation is if FA required that everyone be using exactly the image they provide and nothing else. I don’t think that would be a good thing.
Certainly it makes sense to have accurate up to date docs for the sdcard image and for piaware itself, and I’ll put that on my list. But once you start tweaking stuff - well, it gets harder.
It’d be great if the community could document/support the tweaks that people do. This happens already in various places but there is no one place to go to look for all the changes. Maybe you could maintain a list?
I think the whole idea is that outside of the PiAware SD card image there is a learning curve to being able to replace dump1090 with objs version, and it’s better to have to read around and understand exactly what you’re doing, rather than having your hand held and then breaking something you don’t know how to fix.
I imagine for a number of people dump1090-mutability is the first piece of software they’ve ever compiled from source.
It is a hobby for obj and it’s great that he puts so much time and effort into developing, maintaining and answering questions about dump1090-mutability.
I would imagine it isn’t the best idea for the FlightAware staff to be offering support for software they don’t develop or provide via the image.
Just my 2ps worth, others may well disagree with me.
I did put together a quick diagram that might be a starting point here: flightaware.com/adsb/piaware/about
(it does need updating for 2.1-3’s port change, and it only really covers the mlat bits)
obj - i always hated doing documentation my whole life - and did not one single moment wanted you to do this!!!
fa gets data from users for free - easily worth a million dollar per year - they should pay somebody to do the job - that simple.
It would be good to have a ‘How to’ thread that is made sticky - and also set so only authors can update the posts.
then if somone priduces a great post - like ‘How to install & update Dump1090-mutability’ - that post is grafted to the ‘how to’ thread and becomes a reference point.
The thread would probably only get to 5 - 15 posts total.
Would you consider adding another (optional/configurable) flow of mlat positions from the fa-mlat-client to VRS and other external software? My suggestion is to use 30105 (to keep the theme of mlat data going back to dump1090 on 30104)?
Not a bad idea. Listen on 30103 and provide Basestation-format results, like dump1090 does on 30003? I’d like to avoid Beast format for this because, while it integrates better with dump1090 (that’s the main reason the main result path uses it), it does have a tendency to leak out to unexpected places.
As someone already stated, applying the SD card image FA offers is the simplest form to implementing an ADS-B feed. Outside of that it’s a hobby that people freely donate their time to. I see a lot of folks get upset at the level of support for work contributed freely from folks like Oliver. I don’t get it.
Spend a day doing some legwork and reading the posts, Github documentation, VRS forums (I’m amazed at the # of people that post VRS questions here instead of to the VRS board) or other applicable tool forum. When transitioning off the year long configuration I had (PiAware 1.6 + dump1090) I spent about a day researching the various details and documents to move to PiAware 2.1 + dump109-mutability, taking notes and making my own guide along the way.
