FlightAware Discussions

Graphs for dump1090 -- my version with install script

Is it exposed in a json file for reliable access?
Until it is, no.

Maybe it is and i just don’t know i haven’t looked at dump1090-fa much recently.

It’s logged in stats.json.

Is it easily possible to hide certain graphs? On one system, I’d just like to hide all the system graphs.

You need to edit the html, add

style="display: none"

inside the correct <div …asdfs >

1 Like

changed over to armbian buster OS, re installed piaware scripts, airspy scripts, RC14 edit blink apparently now RC16…, tar 1090. All working ok. Installed graphs 1090, there were a number of un populated graphs. Fault checking procedure and results on armbian buster 1090 graphs - Pastebin.com. You can see a number of errors .

Now that it’s one hour later, are they there?

Sorry been to sleep, but 5 hours later, still not there.

df -h

Maybe no more space in /run?
The logs don’t really tell me much.
Maybe just re-run the graphs1090 install for good measure :wink:

root@odroidn2:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev 1.4G 0 1.4G 0% /dev
tmpfs 370M 46M 325M 13% /run
/dev/mmcblk1p1 114G 2.3G 110G 3% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
tmpfs 1.9G 8.0K 1.9G 1% /tmp
/dev/zram1 49M 4.8M 41M 11% /var/log
tmpfs 32M 28K 32M 1% /var/cache/fontconfig
tmpfs 370M 0 370M 0% /run/user/0

I did a unistall, and ran a re install but same scenario. FYI, the de install did not remove any data, on the re install, I still had data from the last 5 hours.

Right, uninstalled the database, uninstalled the graphs. Re installed the graphs, in the install scripts, there is this one error, I hope I copied the right section:

Process: 3612 ExecStart=/usr/sbin/collectd (code=exited, status=1/FAILURE)
*** Main PID: 3612 (code=exited, status=1/FAILURE)***
dpkg: error processing package collectd-core (–configure):
*** installed collectd-core package post-installation script subprocess returned error exit status 1***
Setting up rrdtool (1.7.1-2) …
Processing triggers for man-db (2.8.5-2) …
Processing triggers for systemd (241-7~deb10u8) …
Errors were encountered while processing:
*** collectd-core***
E: Sub-process /usr/bin/dpkg returned an error code (1)

It looked like the only error message in the install scripts. Still had data there from last 5 hours and still missing certain graphs.

Nah that’s not it, more than enough space.

Well yeah now collectd won’t even start it seems.

The last log from collect you showed didn’t show everything.
You’ll have to do a restart and then take the log after … maybe more lines or earlier after restarting the service.


Yeah those files are zero bytes … and collectd is too stupid to overwrite them.
I suppose i could do something to automatically fix this.

I am reflashing the mmc, wont take long

I’m puzzled by a big increase in CPU usage by the USB component of ADS-B decoding.

Yesterday I moved my Piaware system to a new location. It was working stably and on the same software versions for over a year. The hardware is all identical, but from an experimental control standpoint I made the mistake of doing all the Raspbian (buster) updates before testing everything at the new location.


Notice the drastic before and after CPU graph results.

I did NOT update tar1090, or graphs1090 until much later in the day, and those updates didn’t cause any visible change to any performance graphs including CPU.

So my question is whether others might have noticed that some Raspbian updates in the past year would cause this (and presumably to everyone else running same), OR if this change is due to something environmental or with the hardware? In either case I would expect more variations than I’m seeing.

I had a similar question here in 2020, but that turned out to be a temporary noise level change, which increased the demodulator portion of CPU usage for a while. This is clearly very different. My noise floor and signal dynamic range matches before the move and the system is functioning properly in every other way I’ve noticed. I checked there’s no throttling.

I even receive FEWER messages per second overall in the new location (because of several big buildings), so I would expect the receiver to have less work to do, not more.

Thanks for any good suggestions. Signing off with the obligatory bow of appreciation to @wiedehopf for all the cool apps.

That seems like an unnecessary radical solution :stuck_out_tongue:

zero-copy issue.
Which decoder are you using and what hardware?

If it’s not a piaware sd-card the quickest fix is probably to switch from dump1090-fa to readsb: Automatic installation for readsb · wiedehopf/adsb-scripts Wiki · GitHub
In that case you also need to rerun the graphs1090 install to make it point to readsb.
Otherwise … the current version of dump1090-fa should also have this fix. (i think, not sure)

And done. And graphs installed, this time with no errors in install script, just waiting for them to get started.

And all graphs up and working :smiley: :+1:

Solved my mystery (in a broad way at least). I discovered that FlightAware.com’s display was incorrectly saying I had Piaware 6.1 (the current latest version), but in fact my Pi was still running 3.8.1, and a similar vintage of dump1090-fa. After updating those, the CPU levels now look just like they did before the Raspbian updates. So apparently there’s something with the combination of new OS packages plus old piaware or dump that is less efficient.