I upgraded a couple of Pi’s to 6.0 last month. There was a missing graph I never was really concerned about. Then I added a feeder this weekend and it appears it’s the “gain” graph. Does anyone know how to get that gain graph to populate? I have serialized dongles in the missing graph pi’s if that matters. I thought it might.
Update the graphs1090 program on the pi(s) that are not showing the new graph.
Thanks - that was it. I didn’t realize I needed an update.
So would the syntax to activate the gain graph be:
sudo apt-get update -c “$(curl -L -o - https://github.com/wiedehopf/graphs1090/raw/master/install.sh)”
then
sudo apt-get upgrade -c “$(curl -L -o - https://github.com/wiedehopf/graphs1090/raw/master/install.sh)”
Thanks.
You cannot run a bash script with apt-get update or apt-get upgrade
This is used only for Debian packages.
Simply follow the instructions given on the github page which say to use this command (copy&paste to your command line):
sudo bash -c “$(curl -L -o - https://github.com/wiedehopf/graphs1090/raw/master/install.sh)”
This command is either for new installations or upgrade of an existing installation.
1 Like
I am also missing the wiedehopf gain graph. I’m running the latest version of graphs1090, having just installed it a couple of days ago. However, I’m just running dump1090-fa on a desktop in Ubuntu (20.04). I’m not running PiAware. So is there some configuration file to change to get the gain graph to appear? Thanks.
Well, after reinstalling graphs1090, and restarting a few times, I have a gain graph! It’s a pretty boring graph, but at least it’s there.
Isn’t that just shooting the messenger?
Maybe the graph is dutifully reporting accurately that it is your data that is boring. 
S.
Well, now that you mention “shooting the messenger”, the graph that really applies to is the one with “ADS-B Tracks Seen”. That graph also shows “Tracks with single message”. My understanding is “Tracks with single message” are really false alarms since you don’t get a single message from an aircraft. So I was wondering – why show false alarms ? However, showing the false alarm rate is useful, because it points up a possible problem. If the demodulator is evaluating a false alarm it can’t evaluate a real message if it comes in at the same time. So, a high false alarm rate can reduce the detection rate. I notice if you use the --fix option (which corrects one-bit errors) in dump1090-fa, the false alarm rate is much higher than if you don’t use that option. Some I’m wondering why the --fix should be used.
Well, it doesn’t really work like that. If you’ve got a collision that makes one message uninterpretable, that’s still the case even if you don’t decode one of the messages. (Not strictly true with the dump1090 demodulator, but in practice it’s close enough)
It’s mostly a question of “what data quality do you care about?”. dump1090 already has a concept of the reliability of an aircraft track, aggregated across more than one message. A single spurious message won’t turn into something visible on Skyaware, and the undetected error rate is usually low enough that false tracks from multiple damaged messages are rare.
Gain settings do affect the undetected error rate (as you throw more noise at the demodulator, it’ll decode more messages that aren’t real) so it can be useful feedback for that case.
If the one-bit-corrected messages aren’t desirable you can ask dump1090 for verbatim data and discard the damaged messages yourself (this is exactly what faup1090 does…)
Ok I see, you’re really doing things in parallel, so false alarms don’t degrade detections. I stand corrected.
Also, I was wondering what was causing the false alarms – interference or AWGN ? My setup is just an rtlsdr dongle connected to a 6dbi antenna. When I disconnected the dongle from the antenna, and just ran on the noise generated by the dongle, the false alarm rate was about the same as with the antenna connected. So, I concluded that I probably don’t have an interference problem. (Granted, it wasn’t a perfect test – some nearby aircraft messages were still received without an antenna.)
I expect it’s mostly AWGN.
There are two main classes of error:
-
the preamble is simple and the detection is fairly aggressive so noise is often mis-identified as a potential message, and the error correction of Mode S messages is not great (at best a 24-bit CRC) so if you throw enough random noise at it, some will pass as a valid message.
-
several message types xor the aircraft address into the CRC field, which causes problems for passive receivers because you don’t know which aircraft was interrogated. The best you can do is look at the CRC syndrome and assume that the message was correct if the syndrome matches an aircraft you know is currently transmitting. However you then run the risk that if there really were any bit errors (in particular, damage to the CRC field itself), then the message might get mis-attributed to a different aircraft with a similar address that’s also flying. Because of the way that aircraft addresses are allocated, it’s actually reasonably common to have aircraft with similar addresses flying in the same area.