No different. Ignore TIS-B reports and indeed, no TIS-B stations. I see occasional Other reports. Will see if there is RSSI there when they come by
That’s the difference between -10 and whatever the top manual gain setting - with the current setup, it doesn’t look like it will over-saturate. When I get the RTL-SDR.com preamp it might change as that has significantly higher gain than the LNA4ALL.
You can see the slight change in peak level at abotu 1750 when I updated the graphs to the one with the per aircraft stats rather than the dump1090 stat. I don’t think that difference is big enough to cause any problem.
Maybe those are the TIS-B stations.
Anyway no way to actively ignore TIS-B stations in 1090 MHz because they are not marked as such.
Well the thing is, the peak won’t go beyond -1.5 no matter how high the gain.
I believe it’s due to the RSSI measurement in dump1090-fa or something.
Oh right airspy measures the amplitude of the signal and dump1090-fa does a RMS on the signal.
It’s a different computation in any case
People just need to be aware that the peak won’t go beyond that number no matter how high the gain.
It’s also not really a good way to tell if you are oversaturating the rtl dongle.
But for that we have the Messages >-3dB anyway, which of course is only an estimation as well.
So you might now say that gain doesn’t look too high on the Signal Graph, but it might actually be already too much gain.
What’s the result of this command right now:
awk "$(cat /run/dump1090*/stats.json| grep total | sed 's/.*accepted":\[\([0-9]*\).*strong_signals":\([0-9]*\).*/BEGIN {printf "\\nPercentage of strong messages: %.3f \\n" , \2 * 100 \/ \1}/')"
Currently Percentage of strong messages: 2.058
, however I changed the gain back to what it was before. There is seemingly a huge gap between gain at 49.6 and -10. There were definitely way too many strong signals with it set to -10:
Difference is around 6 dB.
Anyway despite maybe some people increasing their gain unnecessarily, the graph is more useful for people who understand it.
Just a new sight picture to get used to.
Now it’s pushed out, you can update in a couple of minutes and tell me if it’s working as intended.
So, funny thing. On the RPi I see this:
Since these graphs are somehow moved to the odroid, on the odroid I see this:
On the pi it the update seems to have made changes to existing data, but now new data are shown. On the odroid the ‘old’ version’ is shown. On the odroid I have changed the /etc/collectd/collectd.conf file for the variable:
URL "http://localhost/dump1090-fa" URL_978 "http://192.168.86.251/skyview978"
The ‘251’ refers to the pi and 250 to the odroid.
Do I need to update the odroid? In other words: where is the actual graph generated?
That’s the updated graph.
The other graph you see is plotted with the old version only showing peak average minimum.
The new graph would normally show a green band, but you don’t have data for that yet.
Yep, it works. Because the number of observations is so small, the minimum and the first quartile are identical for some cases. Similar for the maximum and the third quartile.
Everyone please note that i’ve enabled a script that automatically removes unneeded parts of the round robin database files.
This applies to most, but not all database files, because for some the full functionality including min or max is used.
I’ve done that for my graphs for quite some time and they work nicely.
For example for all the CPU data, only the average aggregation function is used in the graphs.
So you can delete basically 2/3 of the data because you don’t need them.
Once min/max is removed from the rrd file, min/max also doesn’t need to be updated when values become older.
You can still use a maximum or minimum in the graphs for those data, but for longer timespans it won’t represent the actual maximum, but rather the maximum of averages which were calculated when propagating the data for the next coarser interval table.
So in regards to doing something similar with quartiles and median for the range:
Would a minimum range/distance make sense?
I suppose it makes sense if only to make the statistics complete
Yes, it does make sense. At least to me
That graph is not very nice for me, this will thus not happen
Good question.
When I look at my graph, it has the vertical axis range from 80 to 300. This would then become 0-300. You could even force the start at 0 as a natural starting point (I don’t feel strongly about it). When the graph starts at 0, say, it would make the quartiles (the median being the second quartile) also readable. I’m guessing that the quartiles will be less jagged edge.
The minimum distance would be close to zero, and a bit harder to interpret. How useful is it to know that the closest airplane overhead is 3 nm ? I suppose for consistency only. You could make the minimum a red line (like the minimum RSSI)
Well, it might be useful for some people with few aircraft that fly close by
yours looks sort of, kind of okay, really.
I suppose if the minimum is like 10, 20, 50 nm whatever, it would be nice to see
Range graph modification ready for testing.
(only if you use the nautical mile graph)
Keeping 3 versions of this graph up to date is ridiculous -.-
Sorry for my unsolicited advice…
Looks like this. Note that this likely to be accurate given proximity to 3 major airports (SFO, OAK, SJC). The closest is missing a unit (NM).
Looks nicer than I thought it might…
For consistency purposes, you make one more change to the ADSB Signal Level graph. Make the peak level line bright red (just like the Peak Range in the Range chart) and the Max signal dark red (just like in the Max Range chart). Splitting hairs. And practically there will be little difference in what it is now in the Signal Level chart…
You are making some of what I was working on somewhat redundant…
Don’t let me stop you though.