I’m also running a second SDR-RTL for AIS-catcher on my Pi5. I tested running the Airspy R2 at 24 MSPS for 48 hours and had no MLAT problems.
The USB demands for AIS-catcher may be lower than flight tracking settings, but I suspect that the Pi5 could support running two airspy dongles. Has anyone tried this?
Also running the new RC31 update on a Pi4/4GB. E at 60, letting the CPU use as much as it wants. CPU usage increased about 5 to 10%, and minimal heating as the system is at 46C in a Florida garage. I tested the Airspy R2 on both the USB2 and USB3 ports, and found better results on the USB2 ports.
Nicely done on the update, and I believe we all appreciate your work tweaking the code.
Gene
Running RC31. Appears I have a slight increase in variation of preamble filter values since its start 24 hrs ago
Airspy RRSI may be a bit more wobbly? Hard to parse. Running at gain 17
My CPU increase with this release was caused by losing the -P value when I ran the airspy–conf script update today. Adding a -P value back in in the config reduces CPU again… Duh me.
@wiedehopf
Hi,
I am not an Airspy owner, but like to read about other hardware.
Since you mentioned AIS-catcher, here are the typical data rates for that and some of the common mode-s decoders.
0.288 = AIS-catcher min rate “-s 288K” (works fairly well)
1.536 = AIS-catcher default value if no -s xxxK value entered
2.304 - AIS-catcher max rate for RTL “-s 2304K” (works slightly better than 1536)
2.0 = original Pi dump1090
2.0 = original windows dump1090
2.083333 = dump978-fa
2.4 = dump1090-fa and most other modern versions
These are the internal sample rates for a few of the commercial receivers, but not of course the actual data rate between the receiver and computer. These are not USB rates.
12.0 = Jetvision Beast, Radarcape, and Air!Squitter
20.0 = Kinetic SBS-1/3 and SBS Puck
I don’t remember the internal sample rate of the PlaneFinder Radar or which model it is based on. Again, I am not an Airspy owner, but if you are able to run that reliably at 20, that puts it in the same category as the excellent SBS-1 and SBS-3 for mode-s mlat. I don’t keep up with the Airspy software, and don’t know if they now support mode-a/c for mlat. That has been an issue for some of the Airspy PlanePlotter users in the past.
Regards,
-Dan
cat /etc/os-release
dpkg --print-architecture
uname -m
I guess i should test the CPU use of a couple more of the compiles.
Also, add your CPU usage graph please.
Generally RC31 might use some more CPU at preamble filter 60 which is expected and also yields small returns (beynond premable filter 40, returns are really small already, so that’s just how it is).
Edit:
Checked the arm64 compiles, buster is a bit slower than bullseye and bookworm compiles, but not significantly.
But i haven’t tested the armv7 compiles.
The update script shouldn’t touch /etc/default/airspy_adsb.
Are you editing the service?
Color me a bit confused 
And really i’d just put all the pi5 CPU stuff to the defaults, no need to use all the power all the time.
Not sure how much of a difference it makes on the pi5 but i assume it will.
Ofc the CPU percentages aren’t as steady anymore but just using power for some CPU percentage graphs seems kinda meh.
I used the install script… I couldn’t remember how I originally installed airspy_adsb on the Pi 5. I should have paid attention.
Yep, I removed the overclock earlier. Left force_turbo on for the moment.
After years at 12 MSPS, 20 MSPS SNR looks wonderful.
I also raised my antenna height on Aug 8 so my mean SNR trend is lovely this week! As are my stats. 
pi@Airspy:~ $ cat /etc/os-release
PRETTY_NAME=“Raspbian GNU/Linux 11 (bullseye)”
NAME=“Raspbian GNU/Linux”
VERSION_ID=“11”
VERSION=“11 (bullseye)”
VERSION_CODENAME=bullseye
pi@Airspy:~ $ dpkg --print-architecture
armhf
pi@Airspy:~ $ uname -m
armv7l
OPTIONS= -v -t 90 -f 1 -w 5 -P 10 -C 95 -b
[Edit] RSSI and Noise are more Saw toothed
Replaced the arm 32bit compiles using the Raspbian 32 bit gcc.
Seems it improved the CPU usage for the 32bit arm compiles a bit.
At least for bookworm, don’t think there is a noticable difference for buster / bullseye.
But feel free to try if you’re on 32bit.
If you want to minmax CPU usage, you’ll just have to run 64 bit Raspbian
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)" [...]
pi@thespeedycab:~ $ dpkg --print-architecture
arm64
pi@thespeedycab:~ $ uname -m
aarch64
pi@thespeedycab:~ $
Yeah, I am on bullseye. I suppose I could upgrade to bookworm. It appears that CPU has been lowered for a day or so and has increased backt to old levels since (slightest increase, TBH)
I believe the following code allows running 32-bit binaries on raspian:
sudo dpkg --add-architecture armhf
sudo apt update
sudo apt dist-upgrade
sudo apt install libc6:armhf libstdc++6:armhf libusb-1.0-0:armhf
ldconfig
Found it already ty
On arm64 there isn’t much diff.
The preamble filter looked like you were hitting performance issues but doesn’t seem so.
Possibly it’s just the cpu frequency going back and forth.
Seems like enough headroom to just set -e 60 and not use -C
-e 60 still has an emergency mode to lower the preamble filter if there is issues.
This issue is more complicated than you think. It’s more than just the avionics “recovering”. On airliners and probably many larger business aircraft the ADS-B position information isn’t exclusively coming from GPS data like it does in small airplanes. What is being reported is where the flight management system (FMS) thinks it is. These systems use GPS only as one if its inputs. There are multiple ways to derive position. Large modern aircraft all use inertial navigation systems that start out in a known position and then use gyroscopes and accelerometers to track its changing position in space without any outside input. Those systems will report their position to the FMS. The FMS can also use radio navigation aids in range to triangulate its position. The system will literally tune up different VORs and DMEs, taking bearings and distances to compute its position in space. Combined with the inertial system you can get a fairly accurate position of the aircraft assuming there are enough radio navigation aids in range. The position won’t be perfect but it’s accurate enough for “Terminal” operations which usually require a navigation precision of 1 nautical mile or less. As GPS has gained acceptance it also became another position input to the FMS that it will use to derive position. In many aircraft these days GPS updating of the FMS position has become the default mode. Some aircraft even turn off the updating of the FMS position by VOR or DME, although they remain selectable options during a flight should GPS become unreliable.
So that brings us to the issue of GPS interference and how to deal with it in the plane. Different airlines and different plane manufacturers will have different procedures to deal with this. I would guess that if a flight is expected to be in the vicinity of GPS interference that they might proactively disable GPS updating of the FMS position. If that happens the accuracy of the FMS position will be degraded, as the other methods are not as accurate as GPS. And if you go right back to inertial updating only, that position gets worse with time in a predictable manner. The inertial navigation system builds error as it flies so the estimated position slowly diverges from the actual position. These systems are what we would use if a plane was over the ocean and lost its GPS. You just coast on the inertial system. They still remain accurate enough to get through your oceanic portion of the flight and back into a radar environment. They are actually amazingly accurate over enormous distances considering they receive no external position input after their initialization position.
So why doesn’t the aircraft position fix itself? That could be an airline practice or a recommendation from the manufacturer. After disabling the GPS updating and flying through an area of GPS interference it might just be policy not to re-enable the GPS position updating until the plane is on the ground. In that scenario the ADS-B position, which comes from the FMS, isn’t going to be as accurate as it normally would. And it could be getting worse over time if the plane isn’t using radio navigation updating either. Now from an air traffic control sense, planes in this scenario would have informed ATC that they are in a navigationally degraded state and will be given special handling to ge them to their destination. This is a fairly new issue at the current scale. So I’m sure airlines and manufacturers are still coming up with the best procedure to deal with airspace that may have GPS interference.
Are you suggesting all those 787s with the GPS spoofed / jammed are just flying headings from ATC?
Because that’s all they can do if their FMS position is completely incorrect.
I’ve always assumed the ADS-B gets the position directly from GPS while the FMS retains a sensible position using inertial systems.
(i also believe i’ve read about ADS-B standards at some point that require the position be directly from GPS but i can’t find that right now and i’m not 100%)
Oh we’re not talking 10 or even 20 nmi deviation from the real position, rather 100 nmi or more.
See this example, where the airplane has bad ADS-B position even after a complete turn-around:
https://globe.airplanes.live/?icao=70209e&lat=47.477&lon=16.770&zoom=5.0&showTrace=2024-06-16
This would suggest to me that the FMS is showing the pilots the correct position while the ADS-B output is garbage.
(possibly 1 GPS receiver is working, the other isn’t … what do i know)
https://globe.airplanes.live/?icao=88812b&lat=47.945&lon=15.279&zoom=5.0&showTrace=2024-06-08&leg=1
Another example of the issue particularly problematic on the 787 it seems.
Plenty of other planes on the same route without this issue.
(and i believe this issue was fixed, i haven’t seen it in a bit)
The link below is a FAQ page on the FAA site. On that page in the Equipment section there is a question “Must my position source be GPS?”. The link is not working correctly to go to the answer which is “Any position source that meets the performance standards of the rule (14 CFR 91.227) can be submitted for certification. GPS is currently the only available positioning source known to meet all of the requirements defined in the ADS-B Out rule.”
https://www.faa.gov/air_traffic/technology/equipadsb/resources/faq
14 CFR 91.227 can be found here at this link:
https://www.ecfr.gov/current/title-14/chapter-I/subchapter-F/part-91/subpart-C/section-91.227
I would assume that flight management systems are normally able to recognise degradation of GPS position fixes and ignore them, rather than just blindly accept them and pollute the FMS maintained position. There should be some logic by which fixes are compared to identify errors - GPS position, INS position and radio nav aid fixes should all agree within some margin when everything is operating correctly.
Well in the worst case scenario that’s what would/could happen. They could also navigate using radio navigation aids, as in many parts of the world airways are still predicated on old nav aids even though they are actually flown based on a GPS position. Canada is an example of this getting changed. Canada has just undertaken a multi-year process of decommissioning as many radio navigation aids as possible. GPS is now the primary method of navigation in Canada. Enough radio nav aids have been left on to function as a safety net in the case of a widespread GPS outage. That system is designed to get planed back on the ground and that’s it.
The FARs and equivalent regulations around the world like specify that, but that’s largely a “catch-all” regulation. Specific aircraft certifications can deviate from catch-all regs like that.
It’s entirely possible this in particular was a software fault that just couldn’t self-correct. The general public might be surprised what flight crews deal with. Like any software these aircraft also have bugs. I don’t know if its still the case but at one point there was a knows issue with the 787 where it had to be completely depowered every 51 days at least to prevent a potential flight control malfunction that could occur in flight if you hit that 51 day clock while airborne. If an error like this persisted on to the next leg they might have been informed by ATC that their ADS-B transmission were not accurate or something like that. Most air traffic systems over land are still largely based on radar, so ATC would still know where they are. It’s also possible that a controller wouldn’t have any idea that their ADS-B transmissions were bad as they are getting a radar only feed on their screen. ADS-B still has a long way to go before ATC units will be willing to give up radar. In remote airspace where radar isn’t an option ADS-B is already the primary surveillance method for high level traffic and has been for years now. But over land and especially near busy airports radar is still king. Again Canada will probably at the forefront of replacing radar with ADS-B, but that’s still a ways off. Canada has an antenna diversity requirement in order to ensure ADS-B transmissions work with satellite based ADS-B receivers. Canada’s national ATC provider, NavCanada, was the first to deploy and use satellite based ADS-B in an air traffic control system. They did a deal with Iridium to include their ADS-B payload on the new Iridium satellite constellation, which was all on orbit in 2019. Since then virtually every aircraft with ADS-B anywhere on the globe has been trackable by satellite assuming they have antenna diversity. A new company was created, Aireon, to sell this service to airlines, other ANSPs, and companies like FlightAware. I believe NavCanada still owns 51% of Aireon, while Iridium and others own the remaining 49%.
Yes they are, but pilot intervention is often required to diagnose and fix the issue. In many modern large aircraft navigation is now based not on what equipment is installed but the performance of the system as a whole. Believe it or not it’s called PBN or Performance Based Navigation. So in the cockpit that’s often relayed to the flight crew in terms of how precise the planes location is. We use terms like RNP (required navigation performance) and ANP (actual navigation performance). Often those two values are displayed to the pilot. That precision is required and what precision am I actually getting. If you are in a scenario where your position certainty starts to degrade from any cause, which could be equipment failure or something external, your ANP could start to rise. If your ANP exceeds your RNP the plane will alert you. You can also have cases where the 2 FMCs start to disagree on what the position is. Again you get an alert in that case. At that point it’s often up to the pilots to determine what the problem is and then attempt to fix or mitigate it. We have checklists that we use in many of these scenarios as well to give us a process to diagnose and fix or mitigate the issue. Again in a large aircraft our ultimate backup is the inertial navigation system, as once it has been given its initial position, it requires no further input and just keeps track if its location using its internal gyros and accelerometers. We don’t even need GPS to provide us our initial location as every airport has charts that give the LAT/LONG of every parking position. Most airlines will just use the GPS to give the initial position to the INS, but if you’re going over an ocean there’s a requirement to compare the GPS position with the parking position chart before giving it to the INS.
I have an Airspy mini feeding Flightaware located in my loft and during the recent hot weather I was getting warnings about the temperature being about 75°C. One hot afternoon the Rpi went off line and didn’t come back. I’ve since changed to a Pi4 and rewritten the SD card. All the software is working OK as I can see my Skyaware page and occasionally I get an aircraft registering. I should be getting over 200.
Bias t is feeding an RTL-SDR 1090 MHz LNA and then an FA antenna
My airspy config file OPTIONS= -v -t 90 -f 1 -w 5 -P 10 -C 60 -b
Running sudo journalctl -eu airspy_adsb shows it found the airspy and returned the serial number as well as saying that decoding started.
I think the bias-t is not working as I don’t get any volts from the SMA end of the Airspy.
Are there any diagnostics I can run to check if bias-t is working OK?
Hi,
Check if Bias-tee circuit is connected with the proper “polarity”.
“RF” towards the receiver and “DC” towards your antenna.