Graphs for dump1090 -- my version with install script

Change for the 2nd Message rate graph from the first to the 2nd image by plotting the maximum of the value for the time represented by each point in the graph:
image
image

Also included aircraft count in the same way (only aircraft with GPS position)

Note the difference is mostly visible on longer timescales.
In the plots above you can see half a year.

I’ve edited /etc/default/graphs1090, changed graph size to custom and set swidth to 1096.

When I look at the graphs now, the old ‘small’ ones are nearly as large as the ‘large’ ones which is good. However, when I switch to 7 days, 14 days, 30 days, 3 months, 1 year, 2 years and 3 years, they go back to the smaller size. They display the correct wide width on Last hour, 6 hours, 24 hours, 48 hours and 6 months.

/edit - I’ve just tried something different - I set both widths and heights to 1258 and 330 respectively which I thought would make all graphs the same size but they’re not. ADS-B Message Rate and Overall CPU Utilization (US spelling, damn that ‘z’ :wink: )are showing at 1420x425 and the rest are 1258x330. These are their maximum sizes because if I reduce the size of the browser window, the graphs do reduce in size. So I think this is two separate things.

Longer timespans update slower.

I’ve made some changes, so you will be able to use this command to redraw all graphs:

sudo /usr/share/graphs1090/boot.sh

Try one of the presets maybe? :slight_smile:

# set graph size, possible values: small, default, large, huge, custom
graph_size=default

I’d have to modify the web page source to make them all the same size.
That would require displaying them below one another.

But it’s a more or less static web page so modifying them depending on the settings isn’t fun.

1 Like

OK, I’ve regrabbed the graphs and run boot.sh which appears to have resized them all. Thank you.

These are the update frequencies for the graphs:
Every 4 mins: 1h 6h 24h
Every 8 mins: 48 h
Every 30 mins: 7d
Every hour: 14d - 180d
Every 6 hours: the rest

Note that the updates are staggered, so they don’t update at the same time.

As you can guess from the filename, they are all regenerated on boot by boot.sh.
(The images are stored in a ramdisk, so they are all gone after a reboot)

Hi wiedehopf,

I have tried this method also not working. It will installed packages accordingly seen via screen.

Then run the command:

sudo bash -c "$(wget -q -O - https://raw.githubusercontent.com/wiedehopf/graphs1090/master/install.sh)"

This is what I get:-

root@lime:~# sudo bash -c "$(wget -q -O - https://raw.githubusercontent.com/wiedehopf/graphs1090/master/install.sh)"
--------------
--------------
All done!



root@lime:~# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
root@lime:~#

Regards.

I purged all and remove everything with running the install script.

This is what I get:-

root@lime:~# sudo bash -c "$(wget -q -O - https://raw.githubusercontent.com/wiedehopf/graphs1090/master/install.sh)"
Hit:1 http://security.debian.org stretch/updates InRelease
Hit:3 http://flightaware.com/adsb/piaware/files/packages stretch InRelease
Ign:2 http://cdn-fastly.deb.debian.org/debian stretch InRelease
Hit:4 http://cdn-fastly.deb.debian.org/debian stretch-updates InRelease
Hit:5 http://cdn-fastly.deb.debian.org/debian stretch-backports InRelease
Hit:7 http://cdn-fastly.deb.debian.org/debian stretch Release
Get:6 https://apt.armbian.com stretch InRelease [19.0 kB]
Hit:6 https://apt.armbian.com stretch InRelease
Reading package lists... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  fontconfig fontconfig-config fonts-dejavu-core libcairo2 libdatrie1 libdbi1 libfontconfig1 libfreetype6 libgraphite2-3 libharfbuzz0b libltdl7 libpango-1.0-0
  libpangocairo-1.0-0 libpangoft2-1.0-0 libpixman-1-0 libpython-stdlib librrd8 libthai-data libthai0 libx11-6 libx11-data libxau6 libxcb-render0 libxcb-shm0 libxcb1 libxdmcp6
  libxext6 libxrender1 python-minimal python2.7 python2.7-minimal
Use 'sudo apt autoremove' to remove them.
The following NEW packages will be installed:
  libpython2.7
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/940 kB of archives.
After this operation, 2542 kB of additional disk space will be used.
Selecting previously unselected package libpython2.7:armhf.
(Reading database ... 36920 files and directories currently installed.)
Preparing to unpack .../libpython2.7_2.7.13-2+deb9u3_armhf.deb ...
Unpacking libpython2.7:armhf (2.7.13-2+deb9u3) ...
Processing triggers for libc-bin (2.24-11+deb9u4) ...
Setting up libpython2.7:armhf (2.7.13-2+deb9u3) ...
Processing triggers for libc-bin (2.24-11+deb9u4) ...
cp: cannot create regular file '/etc/collectd/collectd.conf': No such file or directory
Failed to restart collectd.service: Unit collectd.service not found.
--------------
--------------
All done!
root@lime:~#

Regards.

apt purge -y collectd
apt purge -y collectd-core

Then run the install again.
The directory /etc/collectd was apparently not present.
No idea how that could happen.

Seems the sd-card is somehow very strange.
Maybe you should just reimage the sd-card if this doesn’t work.

Edit: I’m investigating on my own system after recreating the problem somewhat.
Stand by :slight_smile:

1 Like

I have purged as needed.

root@lime:~# apt purge -y collectd
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'collectd' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@lime:~# apt purge -y collectd-core
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'collectd-core' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@lime:~#

Strange right, the directory /etc/collectd was apparently not present.

Regards.

Yeah my script failed to install the required packages.
Just do it manually the script will be fixed in 15 minutes.

apt install -y lighttpd unzip python
apt install -y rrdtool collectd-core

Then the install script should hopefully work.

1 Like

It seems working now.

Thanks for the great works.

Have a nice weekend.

Regards.

1 Like

New config option: all_large=yes

Makes the small graphs as big as the large ones.

Excerpt from the new default configuration:

# after saving this file, run
# sudo /usr/share/graphs1090/boot.sh
# to update the graphs and web interface

# set to 1 to enable farenheit instead of celsius
farenheit=0

# set range graph to either nautical, statute, or metric
range=nautical

# set graph size, possible values: small, default, large, huge, custom
graph_size=default

# make the small graphs as large as the big ones
# run "sudo /usr/share/graphs1090/boot.sh" to adjust the web interface
all_large=no

If you want to use this new feature with an existing configuration file just add

all_large=yes

Then run

sudo /usr/share/graphs1090/boot.sh

to update the webpage and graphs.

@keithma i believe you were trying to do that a couple of posts up?

2 Likes

Sure was, this is working perfectly. Thank you :slight_smile:

Great.

I remembered that to display the images below one another i only had to change one percentage in the CSS file.
And that change can be made easily enough with some text replacement in the boot.sh script.

When i saw you try i somehow thought it would be complicated and i would have to change all the divs and column stuff in the html.
Not the case though.

Some more changes, most of all to the memory graph.
The memory graph data from the collectd Memory plugin is flawed.

I have written a small python module to collect stats that are consistent with htop:
linux - How to calculate system memory usage from /proc/meminfo (like htop) - Stack Overflow

This means your old memory graph data are no longer useful, the graph will start fresh.

image

Note that the cache is completely available to be used by programs and “become green” if necessary.
Linux generally tries to keep as much as possible in the disk cache just in case you might need it.
Still programs have the unused and cached memory available should it be needed.

Also added some numbers to other system graphs and gave the temperature graph a new default range.

5 Likes

Edit - don’t worry it’s suddenly started working. Must have been some delay with updating graphs.

1 Like

Was just gonna write that :wink:

1 Like

Got a really long-range UAT signal today, kind of wondering if it was an error of sort or anomalous propagation…
image

Getting more UAT traffic these days. Also have a 978MHz coco antenna working that seems to be capturing more signals as well.

Nice charts @wiedehopf works very well.

It’s probably a spurious data point from an undetected bad decode - usually it will just be a one off point.
You do sometimes get weird atmospheric effects that can duct signals from much further than normally possible, though in that case you would expect to see the long range persist for several minutes.

I’ve reduced color saturation on the yellow for the cache so my memory doesn’t look as full.
Optics are so suggestive :yawning_face:

image