FlightAware Discussions

MLAT Antenna Height

I’ve got about 25 feet of coax connecting my orange FA stick to my outside antenna.

I’ve been getting the red MLAT flag occasionally from the beginning. I upgraded the power supply, tried RTL-SDR sticks, and now am on my 2nd orange stick. All running on a Pi 3B+ And now with PiAware 6.1. The MLAT issue is the constant. I’ve verified height using different methods and even the house plat survey.

Everything else about the station works great.

What I’m wondering is if the coax is adding a delay to the MLAT signals that makes the MLAT calculations always think the antenna is mislocated. The error will maybe be especially large for near aircraft since for far aircraft the coax delay would be smaller compared to flight time of the signal.

I haven’t found any way to set the length and velocity factor of a coax cable connecting to the antenna, but coax does add a delay that will always make the signals seem like the antenna is farther from the aircraft no matter the direction.

Anyone know if PiAware does any kind of correction for coax delays for MLAT? That’s the only thing I can come up with now that could cause MLAT issues but maybe there’s something else going on.

1 Like

Pretty sure that’s not the issue, from experience MLAT isn’t quite that sensitive.

First thing to look at would be the piaware logs.

sudo journalctl -u piaware | grep mlat-client | grep -v -e Aircraft -e Results -e Receiver: -e Server: -e Receiver\ status

At night it’s not unusal to lose synchronization when you’re not receiving any aircraft.

Dec 12 02:27:42 pi piaware[673]: mlat-client(89507): Server status:   synchronized with 369 nearby receivers
Dec 12 02:42:42 pi piaware[673]: mlat-client(89507): Server status:   synchronized with 138 nearby receivers
Dec 12 02:57:42 pi piaware[673]: mlat-client(89507): Server status:   not synchronized with any nearby receivers
Dec 12 03:12:42 pi piaware[673]: mlat-client(89507): Server status:   synchronized with 100 nearby receivers
Dec 12 03:27:43 pi piaware[673]: mlat-client(89507): Server status:   synchronized with 107 nearby receivers
Dec 12 03:42:43 pi piaware[673]: mlat-client(89507): Server status:   synchronized with 152 nearby receivers
Dec 12 03:57:43 pi piaware[673]: mlat-client(89507): Server status:   synchronized with 242 nearby receivers
Dec 12 04:12:44 pi piaware[673]: mlat-client(89507): Server status:   synchronized with 240 nearby receivers

The delay because your cable velocity is about 20 nanoseconds. That is 20 x 10E-9.
The internet delay of the packets can be miliseconds. In my case 35ms = 35 x 10E-3:

That doesn’t even take in consideration processing delay in your Pi, to decode those signals.

That is a meaningless comparison as MLAT is unaffected by connection / processing delays (if they aren’t more than a second or so).
It synchronizes and does multilateration based on the sample counter from the SDR which is coupled to the SDRs oscillator.

What is important is that you don’t lose any data on USB which is often an issue.
USB extensions can be problematic if the SDR voltage drops too far for the USB chip on the SDR to work correctly.

Could even be the pi itself in this case.
But as mentioned … if it’s not red consistently you have to figure out first when the problem occurs and if you can see a pattern (of no aircraft).


@wiedehopf & @SoNic67 - I ran the command, grepped for unstable, and grabbed a screen for yesterday and it looks like it’s all through the day. I don’t see that much activity on the MLAT flag on my stats page but am surprised I see this many unstable messages. Dump-1090 is using 26-30% CPU on a top. CPU load varies but is around 1 but was varying between about 0.5 and 1.5 while I was watching.

Also including some messages from today without the grep so you can see the approximate ratio of stable to unstable messages. Way more than I was aware about.

I don’t know if it matters but we have lots of mountains around. I don’t know how much those frequency signals might bounce. I also have a two-story house not far away if that might also cause bouncing. Big flat walls. At any rate, this whole MLAT thing is a big puzzle.

Thanks for the suggestions.

I’d doubt it’s signals bouncing.

You have the SDR connected via an USB extension?
If you have, can you modify your setup so it’s without that extension?

You have graphs1090 installed so you can see stats over longer time?

What’s the frequency?

watch -n 1 vcgencmd measure_clock arm

It varies. Could that be the issue?

@wiedehopf - no USB extension. The orange dongle is plugged directly into the Pi. No graphs1090 yet.

My best bet yet is some relation to the regular GPS jamming at White Sands, you’ve probably heard of that.

Oh, the GPS jamming would affect MLAT? My antenna can see White Sands at least some because I can watch Richard Branson’s flights at the NM Spaceport - 9NM9 for the airport identifier. I see their mother ship and rocket over about 1500 feet AGL.

The synchronization happens off ADS-B aircraft positions.
So if any of the aircraft being jammed don’t downgrade their position accuracy correctly while broadcasting a bad position … yes that could cause issues.
Not sure if there are any though that don’t detect it properly.
It’s a bit complicated.

You could try setting the governor on performance:

sudo sh -c "echo performance > cpu0/cpufreq/scaling_governor"

no, cpu frequency is mostly irrelevant

I do see the mlat server complaining about some some implausible positions at around the time the OP’s receiver was unstable, so it could well be that, if it’s a sustained problem. (The mlat server will try to discard outliers, since bad positions happen regularly, but if there’s widespread/sustained position errors then it’s hard to distinguish that from real receiver sync problems)

1 Like

@obj - would those position error issues you see at the server manifest in the other receivers in the area? Are other stations around here occasionally popping the red MLAT flag on their stats pages? That is hidden from me when I look at other nearby users’ stats pages.

It’s definitely been a sustained problem, though. I’ve had MLAT red flags come and go as long as I can remember since I set up the station.

Been talking with @wiedehopf and I’m probably just going to build a new OS on a new SD and even use a different Pi to see if it has the issue. The current Pi has been through a number of OS and PiAware upgrades/updates over this time. It only does ADSB and that’s all it’s ever done so it’s a minimal install with no desktop and has no keyboard, mouse, or monitor.

@wiedehopf and I have been discussing this via pm since it was faster and easier and there’s a few things we’ve discussed that may have a bearing on this.

My station is dedicated to ADSB tracking, runs headless, and was sending position data to FlightAware. It is currently an almost two year old system that’s been updated and upgraded along the way. I started sending data to FlightRadar24 since a utility in Flight Simulator 2020 uses their data to put real world aircraft in the sim. (The sim already can do that using FA Firehose data but it’s delayed and filtered/incomplete)

But it’s pretty much always had issues with the MLAT flag on my FA stats page.

I ran the scripts to set up sending data to ADSBExchange since weidehopf has access to the MLAT data if I submit there. As part of that setup, some extra packages got installed and I ran some more updates. Wiedehopf didn’t see anything particularly bad in my data, though. We also verified my GPS location and altitude, I got out an old handheld GPS and verified against the maps and that seemed accurate.

And so far my MLAT flag is still green. It’s an intermittent problem, though. One thing wiedehopf mentioned is I have White Sands in view of my antenna and they apparently do gps spoofing/jamming there and now I know why I see tracks drop out on aircraft flying across the southern part of my state. When they have gps positions but reduced accuracy, I see airlines with minor zig-zag flight paths even as they near KABQ.

I don’t know if it’s strictly for diagnostics or openly known, but wiedehopf set up a map view that filters out all traffic except those with bad gps information - either degraded or missing and interestingly, down south near White Sands is a hotbed. Some web searches show this is well known too. I’d post the link but don’t know if it’s for public use. It’s pretty wild though. When their jamming is active, southern New Mexico lights up. Otherwise there’s just occasional planes at random locations or some in militarized areas of the world.

He also mentioned others around me using inaccurate antenna locations can kind of build in a sensitivity to MLAT positions. I’m going to build a new SD card from scratch and try my station with a fresh build to see if some cruft somehow is contributing to the MLAT flag issue but my guess is there won’t be a difference. I’ve swapped SDR dongles and power supplies. Blue filter, antenna, cable, and Pi are all the same. As noted, there were more software updates that got prompted by the ADSBExchange scripts install.

So I’m on alert, waiting for a red MLAT flag to grep logs and let him know so he can sift the MLAT data to see if we can nail it down, but it could be there’s nothing I can do about it. Still have some things yet to do and investigate but it could all come down to the radio environment where I am.

I’ll update if anything changes or we get more information. I don’t expect it but the Pi will be working slightly differently now that the ADSBExchange scripts are running. I had already done updates and such to move to PiAware 6.1 but some things got updated with that change. It’s now a slightly different Pi OS and app set running.

I really want to thank @wiedehopf for all the help through all this. We spent a fair amount of time sussing things out and getting ADSBExchange all working properly with a bit of frustration from me forgetting my block everything and open holes for specific traffic. The local ADSBExchange page uses port 80 and my box only allowed 8080 (PiAware) and 22 (ssh) until he realized I was blocking 80. Now it’s all :+1:! (Except for maybe that MLAT flag…)

Here’s what degraded GPS looks like on a DAL tubeliner… Not dramatic but a symptom of the White Sands jamming (I think). Where it drops out entirely (not shown) it’s a dotted line. I thought all those interruptions to the south were signal obstructions by local mountains, but that’s not all that’s going on apparently.

Can you enable another GNSS service on your device? Galileo or Glonass? That may help.
I have a GNSS unit, rather, expensive, that is dual band and can receive on two Galileo frequencies and two GPS frequencies (L1 C/A and L2C)

Hey Jon, thanks for the suggestion. I am not really interested in GLONASS and I’ve already tripled my data upload size with all this by sending data to three tracking services. I’d also wonder how many aircraft are using GLONASS in the US. I know it is used here, though. John Deere equips tractors with GPS/GLONASS receivers for farmers. The receiver I used to verify my antenna location was just a hand held Garmin unit. Would there be an advantage? I’m only receiving position signals.

Sorry, I missed the issue. You don’t want to move and have your position be accurate, it is the aircraft positions that are not accurate because of GPS jamming testing.

This should be resolved when they complete the rollout of dedicate L5C for aviation.
The rollout won’t be completed until 2027, then aircraft receivers will need to be upgraded.

1 Like

Just a progress update that may or may not indicate the root cause but shortly after I started sending data to ADSBExchange, White Sands seems to have quieted down and so far the MLAT flag has remained green. Not conclusive by any means. The real test will be when White Sands fires up whatever they are doing again and I’ll see if my MLAT drops out again.

Update - MLAT flag is still green and this may be the longest it has stayed green since I stood up my station (except possibly last year’s holiday season but I wasn’t watching this close). Meanwhile, White Sands hasn’t been jamming this whole time through the holiday. It’s looking like that’s been my MLAT issue. I won’t really know until they go back to jamming to see if that disrupts MLAT again, but it’s looking good as of 12/26/21.

Update Update - MLAT flag still green as of Jan 3, 22. White Sands has been silent this whole time and the flag has been green the whole time.