I just setup my receive station (127849 - KJPN - Barcroft) using PiAware and the FlightAware ProStick. I’m using an outdoor high-gain antenna and everything is working great except that my location in PiAware is off by about 70’ (basically showing up as being on the neighbor’s house). The Lat/Long is correct in Site Configuration and is accurate on Google Earth but I can’t get a change in Site Configuration to be reflected in PiAware. I’ve tried making a change and rebooting (a suggestion I found from older thread) but it didn’t work. Does the ProStick have GPS (meaning, basically, that the Lat/Long and the map don’t overlay perfectly)? Does it even matter or am I a newbie being OCD?
Short answer - it doesn’t matter (other than it’s visually irritating)
MLAT relies on correct receiver location, but not that level of precision. An error of a few 100 meters will still work fine.
That’s what I suspected. Thanks.
That’s just wrong. It might still somehow work like that, but you want to configure it precisely.
Note that i’m not sure if it would even work with 100m of difference.
The reported inaccuracy was 70 ft, that will probably still work but is still unnecessary error.
Seems you have gpsd running and piaware configured to use it.
I think once that has been done, you need one of the staff to change the setting back to a user set location.
Your gpsd is inaccurate and that’s being reflected in the position you see.
The prostick doesn’t have gps, must be something else you connected to the pi.
There is now an option in the stats control panel that lets you choose between using the device-provided GPS location or providing a manual location:
If this is set to use a device-provided GPS is it then possible to take the site mobile, such that every update is correct for both position on map/distances, and MLAT? Or is this setting still only intended for use with a static site, regardless of how location is obtained, such as with a manually entered location?
Don’t ask how I know this, but depending on the quality of your GPS receiver, the position will wander all over the place, lat, lon, and altitude. When the new GPS location is far enough from the last used GPS location, Dump1090 will be restarted, causing you to miss some messages, MLAT will be messed up and need to resyncronize too. Lots of stuff happens, just look at the /var/log/piaware.log file. Better to use a fixed location where you actually are, than trust the GPS dongle messing with your system. Just thought you might want to know.
On your site webpage, in the right side, where that Site Configuration wheel is, at Precision on Coverage Map you have the option to show it “Exactly” if that’s what you want. Of you can obfuscate the location randomly for privacy by 1km or 10 km.
Thanks, I was asking more from a “is a mobile site using this approach technically possible?” angle, but I agree; in practice I would stick to manually entered details and a site that’s not moving. Even for a site setting up in different locations (eg a hobbyist going to events with a PiAware-in-a-box) I would still use a separate GPS to enter details and work out the antenna height seperately. Even then I’d probably not bother – I’d just VPN back home and watch the details on my home setup!
I don’t know what the threshold is, so few of my local traffic aren’t equipped with ADS-B that a survey wouldn’t be very reliable. However I will follow up and see if I can pick the distance where my site is rejected.
My observations are that a few hundred meters makes no difference.
Edit: Just to qualify “no difference” - it will of course degrade precision, but will still provide useful data.
An error of ~100m is not huge. It’s roughly equivalent to a timing measurement error of about 0.3µs. That is similar in size to the unavoidable timing measurement errors we get from how the clock synchronization itself is done.
So you’re doubling the measurement error, but it’s not 10x or anything. If you have many other nearby receivers, that error won’t have a huge impact. The mlat servers will just end up giving less weight to your data (they measure the clock stability per receiver and use that as an input to the solver; an error in the receiver position ends up looking like clock instability)
But it’s certainly worth getting the location right if you can; no point in introducing extra position error.
I adjusted the location of one of my receivers and at 600m it still synced with about 60 other sites and displayed the location of some MLAT aircraft.
At 1km piaware disabled MLAT and reported a timing or position error.
It is now back to normal.
YMMV
S.
Had one site set to 1000m position error - no timing errors, and still got my ‘one MLAT plane’ for the day.
Thanks for running the test. My ‘one MLAT plane’ for the day doesn’t provide a lot of scope for testing.
Hi,
I ran in to this back in December 2019 and reported it to FA then.
While a small change like your 70’ will be reflected in the site configuration display, it WILL NOT be updated in PiAware. The previous uncorrected coordinates will continue to be used and displayed in htop. PiAware ignores changes < approximately 250 meters.
The way to make them perfect is to make two changes.
-
First move the coordinates > 250 meters away. I did this by increasing my lat by 0.01 degrees = 0.6 nautical miles. This change will restart everything with the new “bad” coordinates.
-
Then go back and put in the correct coordinates. Everything restarts and now both the control panel and PiAware are using the exact coordinates.
-Dan
FA staff,
I reported this behavior back in December 2019 in the direct message traffic related to the post I created here. This link is for reference only for you to locate the direct message traffic. The position error problem is not discussed in the post linked.
When I identified the problem, eric1tran located code that shows home location position changes of approximately < 250 meters are ignored.
Here is the code he linked to:
Here was my suggestion at the time by direct message:
Just my opinion, but while a 250 meter “error” in home location might not impact FA, it could impact other sites that are using the dump1090-fa receiver location for their mlat purposes. You guys might want to consider dropping the 250m to something smaller like 30m or so. Just a thought.
Thanks,
-Dan
Thank you. Very helpful. I will probably not bother trying to correct it for the time being since I’m considering moving my station to a building that has much greater visibility. If I decide to keep it where it is then I’ll try and make the correction.
The configured location in dump1090 is irrelevant for mlat; what matters is the location that the mlat server knows. I’m not aware of any mlat system that uses the parameters passed to dump1090 as a receiver location. FA uses position data sent directly upstream, which is updated every 5 mins or every ~250m, whichever comes first. Other systems typically have a manually configured location and don’t see any position changes at all.
Sorry to quote myself but when I was testing and got to the point where both piaware and the Flightaware stats page showed a timing/position error for MLAT (red boxes) two or three of my other receivers also reported the same error message.
One of those receivers reporting that error is located about 1 km away and has MLAT turned off on the stats page.
Just an interesting observation and all my sites are now have their location correctly set up but I am now curious to know if my erroneous locations cause other stations around me to have similar errors.
S
IIRC this is a display/query bug where the error gets displayed against the wrong site when you have multiple sites.
At a low level, timing errors are symmetric in the sense that for a given pair of receivers which are failing to keep sync, the mlat server doesn’t know which of the two is the problem. But the mlat server then aggregates that data across all receiver pairs to decide which are the actually unstable ones and which are the innocent victims. If you’re in a well populated area, individual receivers with sync problems won’t affect other sites.
Thanks.
That means that the MLAT server is smart enough to ignore an erroneous location and it is not an error in the system but just an error in reporting the position error.
Surprisingly, it flags a receiver with MLAT turned off under those circumstances.
S.