My graphs lack the symmetry of your example - but that is informative in itself.
That’s just data from before RC16.
Doing the areas like that isn’t very backwards compatible with missing data.
It’ll clean up with new data.
With new coloring,and showing 5th to 95th percentile - from now on - you can have a much more realistic picture… SNR, Noise and RSSI show the distribution more precisely. Thank you!
Following my instinct, I updated RC16 and graphs1090 at once - and graphs works. Though, I do not know if update of this latest either was necessary or not.
Looking at the changelog, there is an update graphs1090 side also, yes.
RC15 - At night, when there are almost no planes I get a fast and very discrete variation of the -e (with the -C set at target). I don’t know if that’s necessary.
PS: I moved to RC16 now.
So the issue is that the graph isn’t smooth?
Anyhow it’s working exactly as intended, i don’t see any reason to change it.
Post the smooth CPU usage graph instead
Before people noted that the CPU wasn’t at the target lol.
Almost tempted to implement it for the gain as well.
Please, do not smooth everything!
We’ll lose what keeps us so happy: looking at (and pretending investigating) tiny variations on graphs, even we have very little understanding of what most things mean
It is too “smooth” in that roughness
Variations within a single notch is not “too fast changing” - I think. I’d rather call it “good reaction time”.
We seem to be bored, and have so much time to deal with a really minor event on an almost fully flat drawing.
In more serious note…
The theory of automatic control of various systems includes PID types of regulators. Proportional, Integrative, Derivative.
A Proportional-only regulator is fast, but is never precise on a specific value, it will always have a static error.
To eliminate that, you need a PI device to slowly drift to the desired value… That integration time is specific for each process. Tuning perfectly that integration time it is almost an art.
Add the D and you have anticipation of process variation, kind of cutting off the I for big and fast swings.
Looking at that “nervous adjusting”, it suggested me a P-only type of feedback loop.
Usually it is true, but not in a real relation with our present state.
We can talk about changes within the smallest possible notch, and the speed of changes is not 100 hertz. It follows the real changes on your map. Not else.
Inspecting also the numbers, you will see that it is a really carefully controlled tuning mechanism.
Example: Going up 1 single step with -e means only 1/60 of the full available range. It will return to a lower value if cpu load needs some intervention. Stability has priority…
By doing that it so quickly doesn’t actually create more change?
The rate of changes in my setup is fairly slow, planes don’t just zip in and out every ten second in my range…
The integration value would be about a minute or so.
PS: This is not a “complain”, just idle hobbyist discussion.
Do not forget that change is the smallest possible step.
A control mechanism always hesitates when trigger value is close.
Using automation has to force you to accept some compromise.
For the price of even slower changes, you’d pay by a lazy reaction when stability of the datastream from your receiver should be saved. I think, this is our compromise.
If I am wrong, one of our devs will tell you the whole true story.
Small hysteresis at the decision level solves that.
By comparing the possible difference in results of using the two neighbouring values - you can see that it is already a fine intervention, keeping in mind the priorities.
Keeping peace, you’d ask @wiedehopf to create a version for you where real changes are averaged and shown in every 10 mins only (I’d rather wanna see if something is happened)
I do understand what you are pointing at. It works if you are investigating things around a single parameter only. System-wide precision needs to use compromises, since keeping a value stable with “force” can cause anomalies at other points.It is a game of balance.
Bear in mind that you aren’t seeing the actual response of the system in the graphs - it’s reacting much faster than the graphs show, since they have a resolution of only one data point per minute. I don’t know if the figure in the stats file is the instantaneous value for when the file is generated, or an average over the preceding minute. Either way, it’s not responsive enough to see how the adjustments are made.
If it’s advantageous to do so then I don’t see a reason not to - the graphs should reflect the behaviour of the system, not dictate it in my opinion. If the gain line wanders about, then so be it.
If is not properly done, a control system might induce self-sustaining oscillations. That’s all.
Personally, for my specific system, I feel that I have no need to lower the gain if some close-by airplanes come by. DR is plenty and that’s what I love about Airspy devices.
PS: I have plenty of close-by and far away aircrafts. Sky highways…
We have here a small optimization opportunity of 1.5 dB (half step).