It’s a SBS-3; there are relatively few of those and they have a different feed format, there might be a bug in how they’re being processed. Thanks for pointing it out.
edit: looks like bad data from the receiver.
gladly - and btw. this one i found mysterious too - as it collects most data in +250nm distance and is a sbs3 too … http://flightaware.com/adsb/stats/user/Nevrmind#stats-15298
I think that one is just a misconfigured manually set location.
edit: or more than one SBS-3 at different locations feeding from the same source IP (we cannot distinguish them other than by IP)
this is what i found with new ads-b stats calculation - just two samples to show the effect. these are two sites (not mine) doing well in their region since a longer time period - and both support mlat. due to new ads-b stats computing the us-site has a loss of about 30% ads-b aircrafts while the german-site loses about 60% from ads-b. this shows the effect i mentioned before …
us site 4681:
https://dl.dropboxusercontent.com/u/39745369/newadsb_4681.jpg
german site 8431:
https://dl.dropboxusercontent.com/u/39745369/newadsb_8431.jpg
p.s. 21.12.2015 wasn’t recalculated yet
I added the plugin for VRS that you said about in the post. I’m kind of new with something like that. What can you do with this file? Thanks for the help.
It could be worse Tom, here in australia we only have 12 aircraft!.. at least it feels that way now 
Seriously though it has halved the plane count here as well which i find a bit discouraging after lots of tweaking to try and improve things.
First you have to tell the plugin which file to use - in the plugin options, select a basestation.sqb file if you have acquired one from elsewhere or click create database to start a new one. If you have the preview version of VRS you can customise which receiver to use (if you have more than one set up) and whether online lookups are saved. Turn this on to have it store the details of the aircraft (operator, type etc) in the database.
In VRS there are some built in reports - on the map page menu at the bottom is a reports entry. Select that and you get several options - the top one is free form, and allows you to select whatever parameters you want. The next two should be self explanatory, and the bottom three report all recorded flights for a particular registration, callsign or ICAO number.
Note that while it records the positions the aircraft was first and last seen, it doesn’t record the path it took within your receiver range. You can customise the layout of the report a bit once you have generated it.
You could also use some other database software to produce more customised reports, but I’m not even going to attempt to go into that.
Hello
I think there may be an issues with the processing of stats, weekly median values are using a circular reference to arrive at the published set.
http://s1166.photobucket.com/user/grahaml44/media/2015-12-24_14-12-25_zps2shxw983.gif.html?sort=3&o=0
s1166.photobucket.com/user/graha … sort=3&o=0
Thanks, you are right, the median is counting the mlat values twice. Luckily this is just a display thing so we don’t need to regenerate stats to fix this.
Sorry to bring up this “new stats” thing again but my two cents worth is as follows.
I understand that seeing the same aircraft multiple times per day in a 24hr period (LLC’s City Hopping for example) is an unfair advantage over seeing Intercontinental Flights that just come and go once per day. So, counting seeing the aircraft only once is far better globally. However…
As for the Raspi users and mlat. With obj’s help, we have found that my dongle suffers from the Clock Server being Unstable more often than not due to probably the tolerances within my specific dongle and shows up on my FA Control Panel as an anomaly (using PiAware 2.1-3). However, using VRS and Active Display Pro, I am seeing far more mlat data on local, to what I am uploading to FA - according to my FA stats due to this “unstable clock server” and as a result, I am down 50+ places on the ranking table - not that the ranking is that important but just shows what I am not feeding to FA.
Therefore, as others have suggested, could “positions reported” be used instead of ADS-B + Mode S + mlat = Total Aircraft?
Definitely in the right direction! Any chance Flightaware, as a whole, will switch to that? Then everything would be based on hard identifiers. Commercial flight numbers can then be correlated to the transponder’s hex.
I understand that seeing the same aircraft multiple times per day in a 24hr period (LLC’s City Hopping for example) is an unfair advantage over seeing Intercontinental Flights that just come and go once per day. So, counting seeing the aircraft only once is far better globally. However…
Why is it unfair? From a commercial aspect, Flightaware sell the data for FLIGHTS so they don’t ignore the several different journeys per day that many aircraft perform. But the powers-that-be deriving the statistics have decided that once a day is enough 
Unfortunately most non-ADS-B datasources (radar feeds from ANSPs, flightplans filed in various ways, airline-provided info, etc) do not provide the hexid. If you’re lucky, it has the registration. If you’re even luckier, it has the right registration. So pairing up the data is an ongoing challenge…
That wasn’t my argument. I just stated that I understood for the need to change. My argument was the issue regarding mlat issues with some Dongles and their Unstable Clock Servers and why I thought Positions Reported was better.
The mlat data is generated by FA and fed back to you. What you see locally is what is used by FA (and counted in the stats, etc).
(edit: hm, actually, not 100% correct. You will continue to receive mlat data for up to a minute after the last successful position you contributed to. So you might see some mlat positions locally that were actually not generated by you and won’t show up in stats)
This has been fixed and the relevant sites have been regenerated. It was due to bad data generated by some SBS-3s.
When I say Locally, I don’t mean using the “Local link” on my Web Control panel. I use the data received from the dump1090 and my Raspi IP address to gain direct access and not what is fed back to me from FA. 'coz that way, if my mlat data isn’t being uploaded to FA due to my anomaly - Unstable Clock Server. I can still see my mlat data on my local network using VRS.
If you look at this (slightly out of date) diagram it might make things clearer:
flightaware.com/adsb/piaware/about
piaware sends the raw messages to FlightAware for multilateration.
FlightAware does clock synchronization, decides if your data is usable, and if it is, it generates mlat results.
If your receiver’s clock is currently unstable then it does not use your data for those mlat results.
The mlat results go into FA’s internal systems, into the stats system, and are also passed back to your piaware.
piaware forwards them to your local dump1090, or VRS, or whatever you have configured.
So if you are seeing mlat positions, by definition they have been seen by FA. Those positions originate from FA in the first place.
Oh OK, I just learned something. My apologies. I thought I would see my mlat data regardless if they went to FA or not.
So, if my FA Control Panel is set to disable mlat. How then, can I still see these aircraft when I use VRS? Is it because I am receiving Mode-S messages and not mlat?
If you are receiving Mode S messages then I think VRS can be configured to show them in the aircraft list, yeah. Non-ADS-B messages don’t carry position information so you won’t see a position for those aircraft.
Multilateration takes those Mode S messages and uses the relative arrival time at different receivers to work backwards to an aircraft position.