A few weeks ago, I started to use SkyAware Anywhere and noted that the reported number of positions is unusually higher for the hours when SkyAware was kept open in a tab of my browser.
(I used it on the same subnet where raspberry works - on an “always on” Windows based PC, Chrome browser).
Please check if you experience the same.
The subject is active, support and me already have several messages about it.
Theoretically the phenomenon can not occure, but I clearly see the opposite…
Here is the graph: Screenshot by Lightshot
So, please help with testing the situation on your site and report the result. Thanks.
Maybe I do not have some basic info about the way it works, but it is a bit starnge for me.
How can piaware (the client itself) send positions at a higher rate than it is received originally? Planes will not transmit more often.
I thought that all the received positions are already counted by the server…I might have missed something.
The count reported by the server-side stats is a count of summary reports sent to the FlightAware servers. These reports summarize recent information received; they do not correspond 1:1 to messages from the aircraft.
The rate at which they’re emitted varies depending on what the aircraft is doing. e.g. an aircraft flying in a straight line at FL350 might only generate a report once every 30 seconds; an aircraft that’s flying a pattern at 1500ft might be reporting once a second.
When you’re viewing Skyaware Anywhere the report rate is scaled up so that you don’t have large gaps in the displayed tracks for aircraft that otherwise wouldn’t generate reports very often.
If you’re interested in collecting the raw message or position rate seen by your receiver I’d recommend wiedehopf’s excellent graphs1090
It is more understandable now, thanks for your answer.
My simple logic whispered that received messages with positions per (say) hour is a quality factor for the station, so it is shown by the server.
I think, storing the real numbers of sent positions is more important than a “distorted” value for the sake of drawing quality.I really understand the necessity of scaling up the rate for an enjoyable view of map - but why the modified value is shown in the server’s stat? This way, the shown numbers are not related so strictly to the stations received data. The way it works now, mixes the real received data with the activity of the owner (user).
Thanks for the link of graphs 1090, I will enjoy it - I am sure.
I understand also the latency of viewed tracks (let’s say it is 15 sec or more behind the real situation). Method of sending data in bigger chunks is also OK.
Higher sending rate shall not distort the counted positions, it would mean smaller chunks only.
Stats has a meaning where the created numbers have stable “background” and they can not be manipulated.
I think, number of planes alone - sensed by the station - is just an empty number not else. With decoded data (maybe positions) per time or positions per plane - without distorting user activity in the stats would mean something more.
Tech background for displaying should not distort a table of data, where we “measure” the station itself.
example: If I have have 5 samples from a sinusoid signal, I can upscale the predicted drawing points of the line but it shall never alter the number of samples.
It is not a data if I can say about the meaning: “it depends on…”
When displayed positions have higher density than it is graphical upscaling. It is method of correcting the quality of drawing.
When sending rate is elevated, it should never contain duplicated positions in the chunk. I think, sending rate also means smaller data chunks to avoid duplication, does it?
You can see this also on the stats of your profile where the “last connected” time of the receiver is documented and when the stats are updated.
Even sites like Flightaware have a short delay. You can simply check that if you use your local view and the same view on all these Flight tracking sites.
For my site the differencies can be 2-3 miles of position.
I do not have these deep technical skills but for me it’s obvious.
I agree that stats require a stable background. But i prefer having a delayed stats which is validated instead of realtime stats beeing not 100% accurate
I agree.
…but my words are about number of positions in the stats and not the delay. Of course, MLAT needs some more delay to be processed… Filtering spikes and surely invalid packets also need some time…
My problem is the user-activity dependent number shown in a table. Delay is ok but now number of positions are not valid. Seems to be corrupted by a part-process.
Sent positions (with possible duplicates) or pure received positions have not the same value as “data”.
No it doesn’t work the same at all.
FA’s system is more elegant in this regard
The feed map though due to how it works will show the exact same as your local view, just with a slower update rate.
Again, you seem to not have processed what obj wrote … and probably what this thread is about.
It’s about the stats page.
piaware sends new positions only if there is some threshold met, significant turn … certain time elapsed, altitude changed.
So the FA stats page already depends a lot on what the aircraft do not only how many you receive.
Now when you visit anywhere, piaware has an additional threshold to send a new position after 5 seconds have elapsed.
The FA stats system hasn’t changed though, so it’s affected.
Edit:
Just because that point might not have been clear enough yet.
piaware will not transmit all positions you receive.
It’s not waiting 10 seconds and then sending all received positions.
It’s waiting 10 seconds, then sending only the most recent position.
Redundancy for saving huge amount of storage for the database is important.
For drawing a track with straight line, we need two points only. In and out. …then positions stored is 2. All the other received and decoded positions can be filtered out or deleted.
Does it mean anything for the owner of station? I think, means nothing.
What I can not understand: - Why not the number of received (decoded) positions are stored for measuring the receiver’s quality state? I think, stats shall contain only usable data. Technical savings should not mean altering the original values.
Instead “reported positions” we can rename it to “Necessarily stored positions plus extra tracking points if you use SkyAware Anywhere”
Right now, reported positions field shows something about the way how FA works - and it is NOT about the station.
Ranking system is also invalid within areas where most planes use a thin corridor and fly in a straight line. A station built with knowledge and maintained carefully, compared to a nearby station with reduced range and sensivity could show similar number of planes and positions - even if numbers do not really reflect to the real results.
I agree that the report counts are not hugely useful for monitoring receiver performance, but this is not something new. The change in reporting rate when Skyaware Anywhere is used doesn’t change that much. If you’re interested in detailed receiver performance, the answer so far has always been “monitor it directly on your receiver, the website stats are not telling you what you’re looking for”.
Collecting detailed stats on the receiver side and uploading those for display on the website is not a bad idea, but it doesn’t exist currently – and graphs1090 already fills that gap, so…
There have been a lot of arguments about how “fair” the stats ranking system is, but it’s not really a productive discussion. Just take it for what it is, a crude measurement of receiver performance that doesn’t take into account a lot of the site-specific peculiarities. (Note that the report count is not used for the ranking)
Thanks for making the whole clear.
On server side, it is also possible to use the unfiltered sum of detected positions, beside the technically stored data is reduced.
“report count is not used for the ranking”
Using the detected positions as a quality multiplier for ranking would make it more fair. Or for the sake of saving storage, ranking system can be deleted. I think, ranking is less important than relevant info about the station.
