-
Notifications
You must be signed in to change notification settings - Fork 127
Understanding the Performance Graphs
The goal of this wiki is to help users understand and interpret their graphs.
The following are the tools used to create the graphs presented by the portal.
- collectd - a system statistics collection daemon
- rrdtool - A high performance data logging and graphing system for time series data
The configuration file is in fact one in the same as the script that is executed in order to create the various graphs displayed by the portal.
/home/pi/adsb-receiver/build/portal/graphs/make-collectd-graphs.sh
A breakdown of the current ADS-B and systems related graphs is as follows.
Your SDR is receiving ADS-B messages that are 112 bits in length. There is a trade-off between taking more messages per aircraft in a defined time frame or having more aircraft seen but less frequent updates. The blue lines represent the number of messages per second your SDR → dump1090/978 decoded, as an average of the sample time frame.
I believe this is where most people would get confused when looking at this graph. When collectd creates the graphs, using the rrd data located at /var/lib/collectd/rrd/ it graphs the lines as an average of all samples. So, there are plenty of data points that are not graphed on a line. A yellow filled area represented, during that time frame, the minimum and maximum messages per second that was received.
The average of the last seven days of messages received from your receiver.
The count of messages received that had a strong signal. dBFS is decibels relative to full scale. So, if you have a dBFS of 0 then you have attained the maximum that your device can handle. With cables, etc you will never hit 0 dBFS.
How many of the messages received had position reports, or, using MLAT able to get a position.
The number of aircraft that were seen that may or may not have position reports.
Aircraft reported with positions
Aircraft reported without positions
Aircraft reports that were MLAT only.
The number of ADS-B reports of messages, that pertain to a single aircraft. If there was only one message then it is denoted in red.
The maximum range of which your receiver was able to pick up an aircraft. The red line is the maximum distance your receiver could pick up an aircraft in the defined time frame.
The mean level of signal strength. The higher the number, the better (i.e. -20 is better than -23.2 in this example).
The best signal strength you were able to attain during that defined period of time graphed. The closer to 0 that number is, the better.
Wikipedia defines noise as a general term for unwanted (and, in general, unknown) modifications that a signal may suffer during capture, storage, transmission, processing, or conversion.
Your SDR is receiving ADS-B messages that are 112 bits in length. There is a trade-off between taking more messages per aircraft in a defined time frame or having more aircraft seen but less frequent updates.
The count of messages received that had a strong signal. dBFS is decibels relative to full scale. So, if you have a dBFS of 0 then you have attained the maximum that your device can handle. With cables, etc you will never hit 0 dBFS, but -3 dBFS is a good benchmark to try and hit (i.e. with a filter).
How many of the messages received had position reports, or, using MLAT able to get a position.
The average number of messages received by an aircraft, during that period. =SUM(Messages)/SUM(Aircraft)
The number of aircraft seen or tracked by your ADS-B receiver.
How much of the CPU usage is attributed to the SDR that plugs into the USB port of your Raspberry Pi.
Other uses of CPU beyond that of the USB and demodulator.
dump1090 and dump978 are both demodulators. So, essentially, how much of the CPU usage was attributed to dump1090/dump978.