On my stats page I see some positions in the 250+nm range. However, my absolute max range is about 235nm. Could it be the case that the plot is labelled “nm, Nautical Miles”, but the figures are actually counted as Statute Miles? This would make the 250+ category just a 217+nm category and that would tally with what I’m seeing locally.
I think this is or can be setup under your account. Under account then it’s listed under number 5.
My setting there is Nautical Miles. The range graph is also labelled “NM” but I think the actual numbers are in Statute Miles. In reality, I get some hits at 250+ Statute Miles but I never get anything at 250+ Nautical Miles (it’s not even possible for me according to terrain restrictions). And yet the graph shows a significant number of hits at 250+ (whatever)Miles.
@mgunther:
If you feed planefinder.net, check your polar curve there. Below is screenshot of polar curve for my planefinder feed for yesterday. It is all in nautical miles. The polar curves for last 30 days are archived there.
Yes I have planefinder and my maximum range for 12th Jan is 212nm. (https://planefinder.net/sharing/receiver/87839/2016-01-12)
Yet for the same date, FA tells me that I had 261 positions over 250nm! Someone is telling me lies and I suspect it is FA on this occasion. I suspect they are really telling me I had 261 positions over 250 Statute Miles but they are putting a label of “Nautical Miles” on it.
My local graphs show an absolute maximum range of 233 Nautical Miles. That’s more than what planefinder is showing me but still a lot less than 250 Nautical Miles.
@FA Staff: Would you please check the calculations and see if the numbers you are presenting are really Nautical Miles or maybe Statute Miles by mistake?
Yes, the ADS-B stats page distances are computed in statute miles, regardless of your profile settings. I’m not sure I see anything that explicitly claims they are nautical miles. Where are you seeing that?
The unit labels appear to be changing based on the user profile setting (mine just shows “mi” instead of “nm”), but the values are probably not actually being converted to match the selected units.
OK, I checked by changing my settings. The labels and buckets change accordingly. HOWEVER: I still think there is a conversion flaw in the system somewhere. When I view the graph in km, I get over 200 positions in the 450+km section. This is NOT possible. My absolute maximum range is about 430km.
This is my theory: the values are saved internally as Statute Miles. But the code responsible for reading and displaying the values assumes that they are stored as Nautical Miles. This leads to an overstatement of the range by about 15% (i.e. 1 nm = 1.15 mi), regardless of what is set in the user’s profile.
I’ve opened an internal ticket FB61079 on this issue for our development team. Thanks
Let me show with an example what I suspect is happening. For the sake of simplicity lets work with a value of 100 and use the following abbreviations: nm = Nautical Miles, mi = Statute Miles, km=Kilometers.
First, a value of 100 gets written into the database. Note that this is just a value without any meaning. It could be dollars, peanuts or indeed some unit for a distance. It is up to the programmer to attach a unit to the value of 100 and thus give it meaning. Some sophisticated reporting systems allow the recording of the unit together with the value. In such cases, the meaning of the value is always clear. But when only a value is recorded, the meaning or unit of that value is open to interpretation. It may be in the head of the programmer or written down in some comment in the code that deals with the insertion of values into the database.
In any case, a value of 100 is now present in the database and lives there happily without any meaning or unit.
When the time comes to extract values from the database for display purposes, the unit which should be attached to the value of 100 becomes important again. Obviously, the unit should be the same as when the value was written. But this is not guaranteed. If the same programmer writes the insertion and extraction/display code, then you hope that he remembers and uses the same units for both operations. If two different programmers work on the different code sections, then you hope that the unit is documented somewhere and both persons attach the same meaning to the value of 100. But what happens when that link is not there and values are interpreted differently at different sections in the code?
Here is what can happen:
- Value 100 is saved with meaning ‘mi’
- Value 100 is read with meaning of ‘nm’
- 100 nm is converted according to user settings into the following: 100 nm, 115 mi or 185 km
This way, the original range value of:
161 km / 100 mi / 87 nm
“magically” turns into:
185 km / 115 mi /100 nm
That’s an artificial (and erroneous) increase of 15%. And no antennas, filter or amplifiers were needed for that
Edit: I just saw that you opened an internal ticket for that. Please forward the above to them; it may be useful. Thanks!
Now showing Mi on stats page
Just wondering, is there any feedback yet on that ticket? What is the normal response time for such tickets?
mgunther - very good to point this out! looks like they shifted the scale now …
Yes you are right Tom, some change was made in the last few hours. I’ll have a closer look when I get more time.
Yes, this should be fixed now. It was basing its scale off of nm instead of statute miles, so the values should be correct now.