The base Raspbian is probably Jessie?
cat /etc/os-release
I’m sure it works on stretch …
Maybe just updating rrdtool will be sufficient?
Probably on jessie it’s stuck on an very old version.
1 Like
Ah yes, it’s on Jessie.
I basically don’t know anything about this stuff, I pretty much can only follow tutorials and search Google for things etc., so for example; how do I update rrdtool?
Or should I just install the latest PiAware image and install all the other things (feeders for the other sites, graphs, timelapse etc.)
If so; I’m going to see how to backup and restore those things.
I’m personally not a fan of the piaware image, but it works fine. (Just Raspbian Lite is what i use, the piaware image is basically the same with some configuration in the hands of the piawarep-config)
So yes that’s basically the only way to upgrade.
I have some hints about that on the graphs1090 and i’m sure you’ll figure it out 
It depends on your operating system and which program you use, so it’s hard to generalize.
Also a good time to use a new sd-card, just for good measure.
1 Like
Yeah, I think I’m going to build a new FA image and install the feeders again.
Just going to read a lot how I keep the old feeder id’s from the various websites (FA, FR24, Planefinder);
I don’t want to start a completely new installation; want to continue with the old feeds/logs/data etc.
A seamless transition from what I have now to the new image.
Piaware feeder-id
For Beginners - How to GetBack Existing StationNumber in A Fresh Install
Also see this thread:
Howto : Piaware SD card image 3.8.0 QuickstartGuide
Note: Above Howto is for ver 3.8.0 but applicable to ver 3.8.1, except that the link to download image is for outdated image ver 3.8.0, so dont use that link. Instead download latest imahe from Flightaware page:
https://flightaware.com/adsb/piaware/build
FR24 key
You can copy-paste fr24key in Notepad and save notepad, using following method:
cat /etc/fr24feed.ini
receiver="beast-tcp"
fr24key="xxxxxxxxxxxxxxx"
host="127.0.0.1:30005"
bs="no"
raw="no"
logmode="1"
logpath="/var/log/fr24feed"
mlat="yes"
mlat-without-gps="yes"
Alternate method to get the fr24key
https://discussions.flightaware.com/t/announcing-piaware-3-8-1/59021/141
Planefinder sharecode
SSH to RPi and give following command:
cat /etc/pfclient-config.json
The above command will display following long text. Scroll right. Continue scrolling right till you reach end of text, and the share code will be there at the end.
{"tcp_address":"127.0.0.1","tcp_port":"30005","select_timeout":"10","data_upload_interval":"10","connection_type":"1","aircraft_timeout":"30","data_format":"1","latitude":"xx.xxxx","longitude":"yy.yyyy","sharecode":"zzzzzzzzzzzz"}
1 Like
@abcd567 Thanks for the info, some great tips and links.
I did find how to retrieve my current keys/codes, I was mostly looking for how to use those keys for a new install, and I * think * I’ve found how to do that.
I’ll start tomorrow morning and hopefully the whole thing is up and running quickly. 
Sorry, I forgot to give link for Howto install & configure Planefinder feeder. Here it is:
As Piaware SD card image has OS and decoder, you dont have to carty out STEP 1 (os) & STEP 2 (decoder). Scrolldown to following step:
STEP 3- Installation of Planefinder’s Data feeder :
1 Like
Thanks guys. I * think * I have it all running again.
With Win32DiskImager I made a image backup, just in case I screwed something up.
Installed PiAware and the other feeders and they’re all running with the old sharecodes/keys.
I installed the various scripts (graphs, tar1090, timelapse, automatic gain optimization etc.) and that’s all good.
I copied the 2020-03-30 folder that I copied to my laptop, back to the SD-card to the /tmp folder.
Then did this:
sudo systemctl stop collectd
sudo mkdir -p /var/lib/collectd/rrd/
sudo cp -r -T /tmp/2020-03-30 /var/lib/collectd/rrd/localhost/
sudo systemctl restart collectd graphs1090And then:
sudo apt install -y screen
sudo screen /usr/share/graphs1090/new-format.shMinutes counted down and ultimately told me is was “All done!”.
The old data is showing, new data is being written and all I’m missing are just the last 2 days, which is fine.
Now at this point it should be fine right with the graphs using the new database format, and now be limited to the last 365 days 3 years?
Limited to 3 years now.
Typo, I meant 3 years indeed.
Hi!
Currently I’m on the process of upgrading my RPi B to a RPi 4 but would like to keep the graph history, is it possible to move the graph data from the ADS-B Project to this new graph version?
I’ve described the rough way to do it here: GitHub - wiedehopf/graphs1090: Graphs for readsb / dump1090-fa / dump1090 (based on dump1090-tools by mutability)
That’s as far as i’m willing to assist, maybe someone else has the patience to explain the details.
1 Like
The database format from adsb-receiver is still the same, so you will only get 1 year of data and the resolution isn’t as nice as the new format.
So if you want you can change to the new format:
GitHub - wiedehopf/graphs1090: Graphs for readsb / dump1090-fa / dump1090 (based on dump1090-tools by mutability)
Make a backup before if you want 
The script also makes a backup in /var/lib/collectd/rrd/ named as the current date.
@wiedehopf:
A couple of weeks ago I have also created my own ADS-B receiver (base don Rpi 3+) and I am using your version of graphs 1090, first of all, you did an amazing job!
I would have a couple of things what I would like to share with you, first of all, I have selected the right axis unit for the “ADS-B Range” graph, but it is not showing the unit, so I have modified a little bit your script, added “label_right” constant:
range_graph(){ label="Nautical Miles" label_right="" unitconv=0.000539956803 if [[ $range == "statute" ]]; then unitconv=0.000621371 label="Statute Miles" fi if [[ $range == "metric" ]]; then unitconv=0.001 label="Kilometers" fi raxis=1 if [[ $range2 == "metric" ]]; then raxis=$(div 0.001 $unitconv) label_right="Kilometers" fi if [[ $range2 == "statute" ]]; then raxis=$(div 0.000621371 $unitconv) label_right="Statutes Miles" fi if [[ $range2 == "nautical" ]]; then raxis=$(div 0.000539956803 $unitconv) label_right="Nautical Miles"
Than I have added right axis label
rrdtool graph \ "$1.tmp" \ --start end-$4 \ $small \ --title "$3 Range" \ --vertical-label "$label" \ --right-axis-label "$label_right" \
in my opinion, this is useful, so if you also think it is, please take into consideration that you build it in the next release (then it is not needed to modify after each update)
Then I have another question, do you know why the “ADS-B Tracks seen” 2 h graph is not starting at the beginning of the graph, like the other:
Is it possible to fix it?
I’d never noticed this before but I confirm mine is the same.
That’s not possible due to the moving average (see title).
That would break the symmetry with all the other graphs.
If you select a unit, you’ll know what it is
2 Likes
I’m posting in this thread since it’s recent and I’m not sure if my question is actually about graphs1090, dump1090-fa, or some other cause.
I had an SD card die so I reinstalled everything from scratch on Apr 24. So I have piaware 3.8.1, the current dump1090-fa, plus the wonderful tar1090 and graphs1090 packages from Wiedehopf.
The mystery is that according to the graphs I’ve attached below, just after 1PM today my CPU went up and at the same time, it looks as if I had adjusted my gain upward. But it hasn’t!
I haven’t changed the gain at all during the span of these plots, and have not restarted dump1090 nor any other services in over 24 hours. Two days ago, I manually set my gain to 44.5 and I have verified it is still running at that level and it has been continuously for two days (as reported by the command “systemctl status dump1090-fa”).
I am mystified as to how the apparent gain could change with no software alterations and I haven’t even bumped the hardware to my knowledge. It’s all indoors, so water and things like that should be irrelevant. Is it possibly a slightly loose connection somewhere and yet be working this well?
And… no, I have not installed any auto-tuning gain script.
The rise in CPU by the demodulator that began at the same time is what makes me really curious what could be the root cause. It seems most likely to be software related because I’ve also verified no CPU throttling has occurred and the CPU temp graph looks stable.
Thanks!
If nothing has changed in the software then the answer must lie with the hardware. Either a connection has moved slightly and is now making better contact, or perhaps something in proximity to the antenna moved? Try moving things around slightly and see if you can replicate the change.
The increase in cpu will be because the input to the dongle is louder - higher noise on the input means the decoder works hard to try and pick out valid signals. Have you noticed any corresponding changes to range or message rates?
did you consider performing a reboot of the device? I would also check via top or any other tool what overall utilization you have in detail