Actually to me it looks more like your noise level has increased for some reason.
Noise could be from interference or some change in the cabling leading to local interference affecting the signal more.
If your range has reduced at the same time, i’d say it’s some additional noise source you didn’t have before. Which could of course also be internal to the SDR.
Something similar happened to me, suddenly and for no apparent reason the noise level and the signal increased and suddenly it went down again and during that time the messages/seconds decreased a lot, besides it seemed something random. I tried different power supplies, and I don’t solve anything, in my case, with the heatmap utility, I saw that there was noise around 1090 that sometimes was and other times not, I solved it putting a filter, the dark blue of flightaware, and I haven’t had those signal changes again.
Thanks, I think a sudden change in noise does make the most sense here. In the hours since my post, the range of signal levels and the demodulation CPU load have trended back to where they had been the day before. I do have the blue cylindrical FA filter already, and to reduce interference, my Pi has bluetooth & WiFi disabled, but there’s still lots of potentially noisy sources around.
By the way, noise level is not explicitly shown on the graphs1090 displays – is it valid to assume that the lowest recorded RSSI levels approximately correspond with the noise level at that time?
I try to determine SNR from RSSI. RSSI is not a standardized measure with no set scale (0-100, 0-255, whatever). It can be measured and scaled differently in a given chip.
I find the lowest RSSI captured to generally be more useful than the “noise” figure on the old graphs.
So much in fact that i choose to not plot the noise.
The noise is the average level of everything that’s not successfully decoded.
So that includes partial messages, which is all kinds of strange and makes the noise go up significantly when there is lots of traffic.
I just don’t find it useful, thus it’s not plotted.
I have plans to include a temperature sensor on my installation so I can check the temperature inside the case and not only the CPU. I will use the DS18B20 temperature sensor
Any idea if this new temperature could be easily integrated in the Performance Graphs?
They use collectd which has a 1-wire plugin, so it’s certainly possible to have it collect data from it. The graphs are produced using rrdtool, so again it would be possible to modify the script to include data from another sensor. Whether it would be easy or not depends on how familiar you are with poking about in config files etc.
Hello,
I would like to ask you (@wiedehopf) why you set the number of aircrafts scale 10 times higher than the message rate in case of the “ADS-B Message Rate / Aircrafts” graph?
As you can see, in my case it is barely visible/readable the number of aircraft on that graph.
“CDEF:aircrafts10=aircrafts,10,/”
Maybe if we are over this COVID-19 and there will be a lot of aircraft flying again, it would be okay to divide by 10 (or if the receiver is close to a busy airport).
That is why my idea is, would that be possible or makes sense to have a variable to make the division and set the right/left axis ratio? E.g.: Check the Message rate maximum and divide with the maximum of seen aircraft and according to the results set the variable.
So in the case of the above graph, the maximum number of aircraft was 13, the maximum message rate is 22,1, means 22,1/13=1,7 so the right axis ration can be set to 1:1 (–right-axis 1:0) and divide the number of seen aircraft by 1.
The reasoning is the following i think: Once you have a significant number of aircraft, the number of messages per aircraft will reduce in some places.
Other graphs already give you the number of aircraft, so for low traffic just looking at the message rate per ac is fine in my opinion.
I don’t see a reason to touch it, feel free to modify your own version 
I added that message rate graph originally, though I can’t remember if it was me who added the aircraft graph to it. Anyway, the reason for the division by 10 is to get the aircraft and message rate graphs to similar scales for a reasonably busy station:
I don’t think you can have completely independent scales on left and right with rrdtool. The message rate per aircraft never goes much above 30/s and ~300 aircraft is probably not far off a typical maximum for most receivers.
This is currently ony an issue due to low traffic. Once the traffic is back again, the scaling makes totally sense
Now a config option, add this to /etc/default/graphs1090
# set custom left / right axis ratio
# leave blank for default
lr_rate_per_aircraft=2 # default 10
@foxhunter
I have just set up my first receiver in April so I have no data before, I have thought that due to the current situation, dividing with 10 is not optimal but will be if the planes goes up again.
@wiedehopf
Thanks, I will try you proposal, and later I will try to modify mine to change this parameter automatically (if it is even possible, I am not SW guy so let see)
Yes, it’s understandable. Not the best timing for setting up a receiver. There are some other things to consider like the right gain setting.
You will get this managed, i am sure
I have made a small modification, I thought I share with you.
(Maybe it is also interesting for others.)
So I have modified the /usr/share/graphs1090/graphs1090.sh script, but just the aircraft_message_rate_graph() function:
aircraft_message_rate_graph() {
if [ $ul_rate_per_aircraft ]; then upper="--rigid --upper-limit $ul_rate_per_aircraft"; else upper=""; fi
if [ -f $2/dump1090_messages-remote_accepted.rrd ]
then messages="CDEF:messages=messages1,messages2,ADDNAN"
else messages="CDEF:messages=messages1"
fi
if [ $lr_rate_per_aircraft ]
then
if (( $lr_rate_per_aircraft == auto ))
then
maxac=$(rrdtool graph \
/dev/null \
--start end-$4 \
"DEF:ac_max=$(check $2/dump1090_aircraft-recent.rrd):total:MAX" \
"VDEF:maxac=ac_max,MAXIMUM" \
"PRINT:maxac:%1.0lf"|awk "NR>1")
maxrate=$(rrdtool graph \
/dev/null \
--start end-$4 \
"DEF:aircrafts=$(check $2/dump1090_aircraft-recent.rrd):total:AVERAGE" \
"DEF:messages1=$(check $2/dump1090_messages-local_accepted.rrd):value:AVERAGE" \
"DEF:messages2=$(check $2/dump1090_messages-remote_accepted.rrd):value:AVERAGE" \
$messages \
"CDEF:provisional=messages,aircrafts,/" \
"CDEF:rate=aircrafts,0,GT,provisional,0,IF" \
"VDEF:maxrate=rate,MAXIMUM" \
"PRINT:maxrate:%1.0lf"|awk "NR>1")
if (( $maxac == 0 )); then ratio=1; else ratio=$((maxrate/maxac)); fi
else ratio="$lr_rate_per_aircraft"
fi
else ratio=10
fi
$pre
......
(The rest of the aircraft_message_rate_graph() function remains the same.)
It is checking the message rate maximum and the seen aircraft maximum than dividing them to get the right axis ratio.
I have kept the previous options, means it can be set a fixed ratio, or leave it blank to get the default (10), but if you write ‘auto’ in /etc/default/graphs1090 file, then the ratio is calculated automatically:
# set custom left / right axis ratio
# leave blank for default
# set auto to calculate the ratio automatically
lr_rate_per_aircraft=auto # default 10
Maybe it is not the best approach, how I did it (I am a hobby SW guy) but it is working.
Trying it out.
Thanks!
I suppose that wouldn’t hurt to add for those that want it. (available via config)
Later maybe.
I want to share with you, that I made a correction in case of the aircraft_message_rate_graph() script modification because I discovered that if aircraft rate is higher than the message rate, the result will be smaller than one and the script handles just integers, means the right axis ratio will be zero and the rrdtool cannot accept ratio zero, so this line:
if (( $maxac == 0 )); then ratio=1; else ratio=$((maxrate/maxac)); fi
shall be changed to this:
if (( $maxac == 0 )) || (( $maxac > $maxrate )) ; then ratio=1; else ratio=$((maxrate/maxac)); fi
So I have added an additional condition.
Assistance with two questions on graphs1090 would be welcomed. Thankyou.
I’ve upgraded two sites by installing the PiAware 3.8.1 image fresh onto each SD card and then restoring the graphs1090 data, having first backed them up, as described on github. The process has worked fine and both sites have retained all their historical graph data.
I’ve noticed on both sites that the graph horizontal axis is showing UTC, so whereas the local time right now is 23:15 BST (daylight savings are in force in the UK, clocks are forward by one hour), the graphs right now show 22:15 UTC.
That is correct, but I didn’t notice that the graphs were in UTC until now. Is this indeed the case or should the graphs be picking up and showing local time and something has gone wrong?
I suspect the former and that I didn’t notice it until now because I started using graphs1090 when the UK was in GMT, which is the same as UTC, and so until March the graphs effectively showed local time.
The Pi is also set to UTC which is normal for the PiAware image, from memory, and I have never run raspi-config to set localisation on a PiAware image – should I be doing so?
I am checking I’ve not missed something.
Secondly, in /etc/default/graphs1090 I’ve set all_large=yes. There is a comment above that which states:
# run "sudo /usr/share/graphs1090/boot.sh" to adjust the web interface
I took that to mean that it updates all the graphs without having to restart the service or Pi to read the new setting. Is that the case? I decided to live dangerously and see what happened, and it displayed pages of settings for a couple of minutes before ending. I wasn’t sure if I had now broken something that otherwise was working.
In the past I have set this option and then just left it, and at some point the graphs have shown as large without running the command. So I’d like to clarify what the comment is saying.
Thanks.
Regenerating the graphs, otherwise it takes a long time for the longer time frame graphs to be updated.
They show local time as set on the RPi.
How and if you change that is entirely up to you.