tar1090 VS graphs1090

This is cool in concept, but FlightRadar24 has a built-in Augmented Reality feature that works really well.

https://www.flightradar24.com/blog/show-us-your-best-augment...

Also, if I were to build my own local copy, I'd use an RTLSDR to get the ADSB packets direct and base my app on tar1090. https://github.com/wiedehopf/tar1090

I am using node red to readout data from tar1090. https://github.com/wiedehopf/tar1090 Here is the Flow I am using to report if one of our police helicopters is in the air

It’s called tar1090: https://github.com/wiedehopf/tar1090

There's also this, which is how tar1090 works stuff out: https://github.com/wiedehopf/tar1090/blob/master/html/registrations.js

The default setting for tar1090 simply is 4 rings starting at 100nm. Depending on how you are running the software, you can change the default.

If you haven't already: https://github.com/wiedehopf/graphs1090

You can install ADSBExchange and the stats package. You can also install graphs1090 ( https://github.com/wiedehopf/graphs1090 ).

It's worth installing wiedehopf's graph tools which makes it easy to monitor your receiver's performance over time.

There is one effect that might also contribute: How the number of tracked aircraft is calculated: https://github.com/wiedehopf/graphs1090/blob/master/dump1090.py#L307 So ... you can have messages in the message count that belong to an aircraft that's not counted as being tracked. Really you can argue the opposite as well if you were to use 60 seconds as a cutoff (data collection happens every 60 seconds). Then you have aircraft that send one message in a minute and count as "tracked" while well are you really tracking them and should they count? 30 seconds is at least in my opinion a good value that doesn't inflate the number of aircraft tracked as much.