yes. Use the dev version if you want mlat displayed separately & no-forward-mlat-by-default.
When is MLAT coming to Flightfeeder ?
Hey guys, I wouldn’t have known otherwise but a nearby friend of mine just showed me his DUMP1090 interface and I noticed the blue MLAT aircraft on his map. Here is what I see:
http://i.imgur.com/8HuZGHr.png
My MLAT shows enabled on the feeder screen, and I’m starting DUMP1090 with the following arguments: --net --phase-enhance --fix --gain -10 --ppm 76
When I go to the help, I show version 1.10.3010.14.
Am I missing something?
Make a new install on a new SD card (so you can switch back to the old one if it all goes wrong)
Install Dump1090-Mutability following the instaructions here ads-b-flight-tracking-f21/what-is-easiest-way-to-install-dump1090-mutability-t35431.html (read the whole thread)
You sure that’s the solution for me? He’s got the basic dump1090 installation and has MLAT aircraft visible.
works for me, you can always download the latest SD card image and do it that way.
About once a day I get this kind of anomaly.
Anomaly report for PiAware feeder with a MAC address of XXXXXX:
This feeder is not being used for multilateration because its timing information appears to be unreliable. This can be caused by the site location being incorrect, or because your Pi is running out of free CPU.
I have verified that I have lots of memory available and I’ve checked that my location is correct too. If I reboot I will start getting MLAT data for a day or so and this will occur again.
Any idea’s?
If you don’t reboot and just leave it alone, does the anomaly eventually go away / do you start seeing mlat results again?
I’m not sure as I’ve always rebooted. Next time it comes up I’ll let it sit a while and see if it fixes itself.
Because of my location, expectations are low at this point for MLAT positions to show up.
However, occasionally the anomaly message indicates that I am syncing with one or two other receivers but not the four required for MLAT. But, in those instances MLAT aircraft are being displayed on my dump1090 webpage along with MLAT position data.
Question – Should an MLAT plane be displayed at all without at least 4 receivers syncing?
At least everything seems to be working and eventually there may be more receivers coming on-line and we’ll be able to provide MLAT positions.
There are a few things going on here.
- the status is a 5-minutely-snapshot; if you are gaining/losing sync a lot then it may have just seen a moment where you didn’t have much sync
- the status only reflects directly synchronized receivers. It’s possible to have a situation where, say, you (A) are synchronized with receivers B and C, and B is synchronized with D. In that case the overall group can still do mlat, even though you have no direct synchronization with D. You need some unusual reception patterns to have this happen, as for mlat to work in this case there must be a mlat target that all of A B C D can hear, but if A doesn’t have synchronization with D then probably there is no ADS-B-equipped aircraft that A and D can both see - so it’s very dependent on receiver overlap and flight paths. The status gathering is pretty basic and doesn’t consider this case.
- you continue to get mlat results for an aircraft for up to a minute after the last result that your data contributed to, so even getting one result is enough for the aircraft to show up for a while
OK. Let me know if it does come back by itself. It’s meant to, assuming the underlying instability goes away.
There are a few things going on here.
- the status is a 5-minutely-snapshot; if you are gaining/losing sync a lot then it may have just seen a moment where you didn’t have much sync
- the status only reflects directly synchronized receivers. It’s possible to have a situation where, say, you (A) are synchronized with receivers B and C, and B is synchronized with D. In that case the overall group can still do mlat, even though you have no direct synchronization with D. You need some unusual reception patterns to have this happen, as for mlat to work in this case there must be a mlat target that all of A B C D can hear, but if A doesn’t have synchronization with D then probably there is no ADS-B-equipped aircraft that A and D can both see - so it’s very dependent on receiver overlap and flight paths. The status gathering is pretty basic and doesn’t consider this case.
- you continue to get mlat results for an aircraft for up to a minute after the last result that your data contributed to, so even getting one result is enough for the aircraft to show up for a while
I appreciate the explanation and it really helps understand what is going on. My guess is that the essence of our concern is your first item. Since we are in the shadow of mountains on two sides, some aircraft are only seen for a few messages and thus the sync would be of short duration. The anomaly message would not be timely enough to really tell the story.
When we do see MLAT positions, they are usually of short duration even though we may continue to receive messages (without positions) for quite a while longer.
Have recently installed dump1090-mutability 1.15dev and associated dump1090 webpage upgrades. All is working very well
Thanks again.
Richard
Anomaly report for PiAware feeder with a MAC address of …:
Multilateration has synchronized with only 1 nearby sites. A group of at least 4 synchronized sites (including your own) are needed to produce multilateration results.
I guass i can’t do anything against this anomaly exept hoping for more feeders in my region?
You have a fairly small range on your receiver, but being in a valley in the alps is a problem.
From Innsbruck you should be able to receive planes from Lictenstien in the west to almost Linz in the east and Bolzano to the south - is there anything you can do with your antenna?
There are two other PiAwares nearby - just need one or two more maybe 20-30Km away in the same valley
What version is your dump1090 reporting with a -h? I just updated everything via apt-get and I’m on the latest.
dump1090-mutability --help
| dump1090 ModeS Receiver dump1090-mutability v1.15~dev |
|---|
Had a couple of more blips with this and let it sit without reboot. Seems to come back on later but then loses mlat again. I guess that’s normal behavior?
Normal in the sense that it’s what is expected if the timing is occasionally unreliable.
It’s still an open question exactly what it is that makes the timing unreliable, the server just sees the end result - I need to throw some time at this to try to get to the bottom of it. It may just be a hardware limitation at the end of it all 
Hi all,
I too have started getting the *“This feeder is not being used for multilateration because its timing information appears to be unreliable” * in the last few days - the only change in my setup being the NTP server I’m getting my time sync from - I’ve gone from my Windoze based stratum 1 server to my Pi based stratum 1 server. Both are GPS locked and are within uS of each other.
I might try changing the ADSB Pi back to syncing to the Windoze box and see what happens…
Setup here is a Pi running mr-dump1090/FR24/FA.
Cheers.
Andrew
rodeo (T-YSBK22) on FR forums