Well if you are averaging over a week, that’s still nice and a different point of view.
I’ll make it more consistent tomorrow and clean it up some
Finally got a position-less report. It is just a plane for which a position was not read / obtained. It is not a TIS-B station. It does have a RSSI, of course.
Also i’ve reverted the min/max removal for the files that don’t need that.
I believe it was somehow screwing with my data.
I’ll do another test before screwing with data that’s not mine.
I’d recommend updating once more before the next reboot for people who updated today.
(so the removal script doesn’t run.)
I believe the error was because i ran rrdtune while collectd was running.
(the script stops it before making changes so it should be fine, still i want to test it again)
I was actually drawing 3 graphs of the last 30 days showing box plots for each day - this a more efficient way to do it though, so i’ll just remove those graphs and do a slightly different layout.
I guess that I qualify for that
Hmm i don’t think i like those quartiles in the max range graph.
In the signal graph it fits better.
Probably gonna just revert it to the old look.
It’s not really that, feels like it’s superfluous information.
Maybe i’ll just collect the data and make the graph optional or something.
There are more reported signals than there are reported distances. The graph could still work with fewer observations, but it may mean that the definitions get sharpened a bit to deal with only a handful of observations (not sure what you are currently using though --there’s an easy calculation at the bottom of this page: https://stackoverflow.com/questions/45926230/how-to-calculate-1st-and-3rd-quartiles). I like the extended version. But can see the lack of added value in other cases.
Don’t have any interpolation going on right now, it was just a simple implementation making sure i don’t go out of bounds for the array.
But that’s sure possible:
Percentile - Wikipedia
I guess we gonna follow NIST, huh?
The primary variant recommended by NIST.
C=1 it is!
While i wouldn’t implement RSA and would trust a library, what is the fun if you’re going to use a statistics package
That works. Glad that the principle works at least.
Actually NIST recommends C=0, but C=1 seems more continuous, so i’m gonna still use C=1.
Percentile function now used:
def perc(p, values):
l = len(values)
x = p * (l-1)
d = x - int(x)
x = int(x)
if x+1 < l:
res = values[x] + d * (values[x+1] - values[x])
else:
res = values[x]
return res
It’s described here: Percentile - Wikipedia
Note that my code is for a zero-based list, while the Wikipedia article assumes one-based lists.
int() in python rounds down, just as required.
Testers welcome as always.
I think i found the problem with getting rid of the unused MIN/MAX in the rrd files.
It seems i need to pass the DELRRA commands in reverse order, highest number first.
Otherwise it seems rrdtune gets confused and messes up the data.
Will test some more and reintroduce that optimization soon.
Seems to reduce collectd cpu usage and graph cpu usage.
Also reduces disk writes and reads quite a bit.
Per default the RRD saves basically 3 data sets for each value, MIN/MAX/AVERAGE.
This is necessary for preserving minima/maxima when going to coarser time intervals for saving the data.
Let’s say our maximum range has these values in 3 consecutive minutes:
100 180 100
Now when consolidating the data for storage in 3 minute intervals, only one value can be saved.
The average of those values is 127, so this is saved.
If i want to plot the maximum range on longer timescales, the range would be much reduced due to averaging.
Thus 2 other propagation functions, minimum and maximum are saved.
So for this example you would be saving this triplet:
100 127 180
Anyway for most values in the graphs we only care about averages, thus this complication isn’t necessary and the rrd size and related reads/writes can be reduced.
Please do that (if possible). I like it since I don’t have time to watch the screen and need to tune my station based on the few close-by aircrafts and the more frequent distant aircrafts.
Your work is very appreciated!
Some more changes:
- simplified the range graph to have only one unit at a time depending on configuration
- color scheme adapted to match graphs before all the changes
I do miss the kilometers on the RHS of the ADS-B Range… Any chance of bring that back in? Or is it either one to choose & set and that’s it?
# set range graph to either nautical, statute, or metric
range=nautical
Wanted to save the annotation for the right side units.
But i can make an extra config option to optionally change the right side to another unit.
Also before there were 3 versions of the graph that i needed to update when making changes.
And such code redundancy is just bad
It’s now available for configuration in the settings.
# set range graph to either nautical, statute, or metric
range=nautical
# set the right axis unit: (leftaxis, nautical, statute, metric)
range2=leftaxis
The range setting determines the units of the number in the text below as well as the left axis.
Right axis setting is independent.
The option will be missing in your configuration file (because the install doesn’t overwrite the configuration)
Just add
range2=metric
This will be sufficient for you.
Looking very nice so far.
If any of you have ideas in regards to the colors or arranging the text differently, let me know.