Thanks for the altitude info. I updated my local test to use barometric altitude and it quickly produced the data quality issue I originally worried about. It reveals some of those bogus altitude readings I occasionally see on my map with the Airspy receiver. Usually just the last message before a plane drops out of range for one reason or another. No issues in over 8 hours using nav_altitude_mcp, switch to baro and within minutes I get the altitude spikes.
So to use baro, I would need to figure out a way to filter those out. Perhaps find a way to require two or more similar alt_baro readings or something along those lines. Out of time for this weekend, so here’s where I pause.
Agreed. The default graphs are all about receiver performance. IMO altitude is bit more useful for evaluation than some of the other traffic behavior metrics like aircraft speed and heading though. It can help you interpret near real time ups and downs in some of performance graphs. And for UAT, I would be able to tell if that 130 nm range reading was really from a UAT aircraft flying under 18,000 feet vs a dual transponder aircraft flying at 40,000 ft (it happens weekly). But yeah, this ain’t about receiver performance.
I’m not particularly keen on adding such graphs but i suppose it could be useful.
An elevation angle graph (which would be derived from distance and altitude) might be even better.
I’ll think about it …
I think an elevation angle graph would be really nice for seeing how much traffic is seen at distance compared to close. That would be good if you could implement it.
What surprised me was quite how much traffic (certainly at my location, 361 ft asl) was at under 1° elevation.
It’s fascinating to watch the elevation angles dynamically updating from SkyAware and traffic above 25° elevation is, contrary to my expectations, quite a minority of the flights seen.
Occasionally the data can seem scewed by the odd helicopter that lands very close by, resulting in a very low elevation angle: but that is because I am using my site’s elevation as part of the calculation.
Normally outliers in the data are a good indication of troposheric enhancements, for both further maximum distance observations and for ground transmissions well beyond the regularly observed ground range.
Actually i don’t want any extra graphs, as i said i don’t necessarily want to clutter the graphs … keeping the selection of graphs as it was some time ago is nice.
Also you can see how much traffic is seen at distance compared to close by looking at the different lines in the distance graph.
The elevantion angle graph would not tell you that.
Today I saw a “gap” in my graphs. is something wrong with my settings or is someone willing to explain what happend. In the stats page of Flightaware it shows I did see some planes.
To reduce writes to the sd-card, data is only written to the sd-card every 24h. A power outage will cause up to 24h of data loss which usually isn’t a big deal. Reboots or shutdowns are not an issue and don’t cause data loss.
Thank you for pointing that out. Every day around 12 aam I am having a small "gap. I know this is because of what you describe in the mention Githup page. But this was for several hours ( almost 5) and that is what i do not understand. But is you say it the same, well so be it
So what happens when you have a power outage in the middle of the day when the data is saved shortly before midnight?
There are troubleshooting steps explained on the graphs1090 page as well, one of them is looking at logs.
If you’re curious about the missing graphs … check it, inform yourselves.
Check how long the log goes back.
Try looking at a manpage and figuring out how to look at more logs.
Thanks @wiedehopf . After posting the graph, I rebooted the Pi to bring down the memory usage from 800 mb down to 200 mb. Will use the commands you have suggested when memory usage shoots up again.
