Whaat? We have a sh*load of oak threes around here, but we can cut whatever we can afford to pay.
I have left two in my back yard, but there are tall trees all around me. They do indeed limit the reception a bit, but… isn’t that bad.
Take a snapshoot of your reception range now, and then compare it with one in December, after all the leaves fell off. In my experience, that’s not that big of a deal.
However the Airspy, hard driven by a proper CPU (20 or 24 MHz SR), can yield more messages/sec than a normal Pi plus an 8 bit dongle can do.
besides not being useful and not counted by FA website… isn’t the Mode-S DF 20 and 21 actually the mode A/C? Those are decoded by airspy now. Radartutorial
DF20 and 21 are CommB. Mode A/C is a separate system that operates alongside mode S.
Mode A/C is much more limited - mode A is a response giving the aircraft’s squawk setting and mode C is the altitude response. The problem with receiving it passively is that there is no difference between mode A and mode C messages. They are both 12 bit replies to an interrogation, and the only way to tell them apart for sure is to be the interrogating radar where you know which one was asked for. A passive listener has to do a lot of inference and guesswork to decide which is which and to what aircraft they apply.
It is therefore of pretty limited use for most purposes - the only system I’m aware of that attempts to make use of Mode A/C is planeplotter which has some kind of mlat that uses it, as well as their beamfinder system which relies on knowing radar head locations and rotation rates.
Yes, that is what I am feeding via the orange FA dongle and dump1090-fa accepts a parameter from PlanePlotter to enable Mode A/C however I suspect that the Mode A/C messages don’t make it across to PlanePlotter as is from airspy_adsb.
I am now getting out of my depth WRT how airspy_adsb / dump1090-fa sends data to PlanePlotter for Mode A/C: anyone else listening here, feel free to chip in
There is some good stuff happening Mode A/C wise in PlanePlotter these days, come a long way in the last year or so with MLAT from different PlanePlotter feeders
It will likely be aircraft that are old enough to pre-date mode-s that are only equipped with mode A/C. That would include some military aircraft, but I suspect it will be mainly older privately owned or GA aircraft that fall into that category. The vast majority of commercial traffic has been using mode S for a long time.
Perhaps you might find small operators in remote areas with only mode A/C, but it’s really an obsolete system that is present purely for backwards compatibility. Most of the transmissions only serve to add to the noise on 1090MHz - I wouldn’t be surprised if it gets turned off eventually.
Mode-S was made mandatory in US in year 1987.
A tentative to rescind that rule, for aircrafts equipped with TCAS II, was proposed in 1996, but was withdrawn in 2005.
The All-Call Mode S interrogation is designed to be compatible with Mode A/C transponders.
I also feed Planeplotter and was hoping that the recent upgrades in airspy_adsb might include a feed of mode A/C data to Planeplotter from an Airspy mini but I’ve tested it and all that is fed are Mode-S messages, unless some changes are needed to my Airspy configuration files, something that I asked on Friday but didn’t receive any replies.
Here’s a plot of the memory utilization of my 2GB Pi4 running the Airspy package but I remember that I noticed the same behaviour when I was still using the FA dongle.
I wonder what would happen happen if there was no reboot for a whole year, would it crash or is there a sort of garbage collector task that would kick in before running out of free memory?
First graph1090 improvements was collectd writing to /run/collectd and then saving the data nightly.
Then at some point i reduced the compression for those files and put them all in one file that’s saved to disk. Not something you’d see on this IOPS graph though.
Then i noticed rrdtool graph was using fontconfig somehow and that was writing to /var/cache/fontconfig every minute when the graphs pictures were created.
So i made the graphs1090 service automatically make that directory tmpfs as it doesn’t need persistence.
That’s likely the second drop.
Are you saying airspy_adsb is using that memory?
I’d suggest it’s something else leaking memory. (as i’d very likely know about airspy_adsb leaking memory)
Should be easy enough to determine with htop?
(shift-M to sort by memory)
That’s your desktop manager, lightdm. You can disable that if you don’t use the graphical desktop. I had the same memory issue. I disabled lightdm from starting. Now my system boots to a command prompt.
lightdm starts x11 if i’m not mistaken, so you’re kinda correct.
If you want to keep the desktop, you could just restart the lightdm service nightly … be aware anything open on the desktop will be lost.
Also that process you’re pointing to is using less than lxpanel.
The VIRT row is actually not important, the RES row is the relevant thing.
And that’s 367 MB for lxpanel.
The scripts will only download the current version.
You’ll have to manually download an old version, unpack it and cp -f to the location where binary currently is.
It has been explained in this thread before if i’m not mistaken.
