Oh yes I see now, its created some random port name, yikes!
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enx001e06369ae7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 00:1e:06:36:9a:e7 brd ff:ff:ff:ff:ff:ff
Do the following:
sudo nano /etc/collectd/collectd.conf
Find the lines i’ve mentioned in my previous post.
Change
Interface "wlp3s0"
to
Interface "enx001e06369ae7"
Then Ctrl-o and enter to save and Ctrl-x to exit.
Restart collectd:
sudo systemctl restart collectd
I now have a graph, it’s empty but it’s there so looks like it should work now as I didn’t even have the box before. Thanks!
Looks like it’s working now:
Also how did you improve your reception that much? Anything that wasn’t working before?
Yes it’s working thanks to you again. The receiption improvement is this was my test box that was on the second floor with the FA antenna in the window, now it’s running on my outside arial. I moved the XU4 to production on the 1090 and left the Pi3B+ running UAT.
@wiedehopf thank you again for creating this! I have two questions, since I’ve installed a few iterations of this: how can I tell what version I am running? I’d like to upgrade my nodes all to the same version (some of them are running the initial release) and if I run the remove script, will it destroy the rrd files?
Just run the install script to update.
The database is always left alone, no matter if you run the install or uninstall script.
(the uninstall is mainly so it stops CPU by creating graphs and will also stop data collection which incurs some writes)
I’m not really concerned with the few MB the database occuppies.
Deleting the database would also be really bad form.
There is no way to know the version you are running 
In doubt just update by running the install script, it doesn’t hurt anything.
I’ve even made a script to convert the database to the current format.
But you only need to do that if you are limited to one year and want 3 years of history.
That’s only the case for people with a database dating back to the adsb receiver project from which i forked my graphs.
I made some minor changes to the database format, but rather soon after releasing the initial version.
Install/update:
sudo bash -c "$(wget -q -O - https://raw.githubusercontent.com/wiedehopf/graphs1090/master/install.sh)"
!!! the following is not necessary for most people !!!
Update database format (might screw with the max range graph a little, don’t interrupt it)
(also: run the install/update first)
sudo apt update
sudo apt install -y screen
sudo screen bash -c "$(wget -q -O - https://raw.githubusercontent.com/wiedehopf/graphs1090/master/new-format.sh)"
Also this takes around 8 minutes, no data is collected during that time period.
(edit: added protection against ssh connection loss, so the process will still complete)
As i said before, this isn’t strictly necessary.
It’s been quite some time since i settled on this iteration of the database format.
Ahh, I love a mystery 
- Thanks! I’ll get to this now
You could note for yourself when you ran the install script and then check here if something changed:
Commits · wiedehopf/graphs1090 · GitHub
Note that some summaries might be very short and you might need to check the actual difference in source code to know what changed 
Maybe i should include a version number, but i don’t think it’s necessary.
You could make the “aircraft seen” a line instead of a bar so the green background/fill goes away. If you try that you may want to make the aircraft seen color a black line to represent the total and then use other colors for the other lines.
Thanks for the suggestion. I’ve decided to stick with the old design for now.
If anything i would change it to all stacking because that avoids lines printing over each other becoming hard to read.
That was my first thought, a stacked bar chart.
I’ve implemented basic signal measurement for remote receivers using the beast protocol.
(beast/airspy)
It just averages the RSSI over all aircraft, but i like it better than an empty graph.
dump1090-fa normally averages over all messages if you are using an rtl-sdr stick.
As always update via the install script:
sudo bash -c "$(wget -q -O - https://raw.githubusercontent.com/wiedehopf/graphs1090/master/install.sh)"
Great work!
Just installed it and it’s starting to populate the graph.
I’m at the end of my fine-tuning period (one week per gain step between 18 and 21), just wished that I had this graph before I started the fine-tuning
But your graphs (modified to work with the airspy) has been helpful in finding the proper setting for my station. As it looks right now a gain of 21 is the best for my location (few close-by aircrafts). This is with the RTL-SDR tripple-filtered LNA and FA-antenna.
High levels, but the bulk of the aircrafts are beyond 150 Nm. A nice piece of hardware, that Airspy…
It really can’t help with finding the correct gain. It’s just because the graph would be empty otherwise.
Even when using a rtl-sdr stick the signal graph is not that useful.
For tuning gain you need to consider the strongest and weakest signals.
Mostly it’s trial and error anyway.
(the >-3dB percentage can be helpful though as it gets you to a setting for fine-tuning)
Now that i think of it, i could just add the weakest and strongest aircraft.
The weakest signal would kinda give a noise reading in a way, so i’ll just use it for that.
The other will be the peak.
But with airspy the peak will basically always be at 0, maybe -0.2 if you are using relatively low gain for the airspy.
Ok, maybe calling it noise would be a mistake.
minimum signal is more accurate, there is already a database for that but it’s not currently plotted.
i’ll just add it to the graph.
Would it be possible to have a graph for Signal-to-Noise ratio? I have no clue what would be needed to populate such a graph and whether the needed information is available
No way. All i have to play with is an RSSI value for each plane.
I’m aware that it can’t be the only parameter to go by. But since I have a lot of numbers in a spread-sheet, the graph may be useful in a broader context.
The most useful parameter for me is positions per aircraft (counted per day and per week based on whats reported to FA). I compare that to a couple of sites not too far away (there are few sites with comparable numbers at my location) by calculating the daily and weekly difference between these sites. Then I choose a gain that gives me the best numbers compared to the other sites.
What I see from my numbers is that since I have so few close-by aircrafts and so many more at 80-250Nm I will benefit more from I higher gain setting than from a lower. The increase in positions reported by the close-by aircrafts when using a lower gain does not compensate for the loss of positions on the more far-away planes due to a lower gain.
When I was using the ProStick+, I had to run a lower gain (28 or 29.7) to get the best results with my method above (with the Uputronics LNA with less amplification and less efficient filtering than the RTL-SDR LNA). The ProStick+ suffered from the closer aircrafts (saw a drop in messages/seconds when aircrafts passed by closely) than the airspy who just keeps going.
If you find yourself in need of a new project I have an idea:
Automatic gain-changing depending on number of planes within different user-defined ranges. Sort of AGC based on aircrafts and distance instead of signal strenght and quality. I would love to have a system that lowers the gain when I get the odd close-by planes and then increases the gain when those aircrafts are further away. Can’t spend the entire day copying config-files and restarting processes to get the proper gain for every situation
I’d just adjust the airspy so close by aircraft are still received.
Increasing the gain beyond that, i’m not sure if it even improves range/ reception at long distance.
If you live 100 yards next to a runway with clear view, then you might have to compromise even with the airspy or live with somewhat reduced rnage when you want to avoid overload.
Minimum and maximum signal have been added as well now.
My weakest aircraft is at -24.1, the strongest at 0
