The timing is not related to the system clock at all, so NTP doesn’t affect it one way or the other. It is the timing of the sample stream coming from the dongle. If the Pi is overloaded, you can drop large blocks of samples (milliseconds) that break the timing. There is also a more subtle effect where some setups, for an unknown reason, drop a few samples (microseconds) randomly which has a similar effect.
Ahhh ok … its a Pi 2 running about 9% average cpu usage - hardly working I would have thought… just a bit coincidental that it started with the preferred NTP server change 
First time poster to the forum but long time reader. After reading this entire thread I believe I am understanding that the anomaly reports for MLAT and timing are a result of the relationship between the dongle and the Pi as opposed to NTP syncing. I was having no trouble with my Pi B+ but upgraded to the Pi2 so I could move the B+ to another location. Ever since I changed over to the new Pi2 I have been getting consistent reports of MLAT timing problems. I have tried 3 dongles in both models and none of them produce timing errors except sporadically in the B+ but all eventually lead to the timing problem with the Pi2. In most configurations the timing problem does not resolve itself until I reboot but not all. Because of this I would be inclined to say that the Pi2 in the problem in the equation but I want to make sure someone else doesn’t see a problem before I replace the board with a new one. Thanks for any suggestions.
I wish I knew exactly what caused this - as you see with your experience, it seems to be hardware specific, but I have not managed to find any particular pattern to it. It may be a subtle timing or interference issue in the USB path that varies from unit to unit.
Any chance you have setup the RPi2 with overclocking? There have been reports that folks using the same config as a B+, that was overclocked, can cause stability issues.
In other words, If you overclocked the B+ (which is good), but swapped the SD card to the pi2 without removing the overclock config, it can cause issues with the pi2.
i think the fastest way examining problems like this is to make a quick fresh install on a different sd card.
since about 48 hours i’m running a second raspi 2 to test the new mlat feature. with about 4,000 aircrafts, 150,000 positions per day and 5-10 mlat-airplanes around the clock - up to now anything works flawlessly. processor load is about 5-9% - mostly dump and mlat.
so - the good news is - yours should too …
I have blue planes somehow, but I do not read blue lines on the right panel. MLAT is not working for me.
To make it obvious I got the following message:
I did update dump1090-muta to 1,15-dev three days ago. Still carry the same message since I install my PiAware.
I have few neighbors MLAT compatible, I do not understand why it’s not working on my hand.
The last though I had was about my router, to open some port outside, but I am unsure this is the key to the problem.
Any though?
thank you,
Regis
@obj - Thanks for the quick response. It is amazing how active this community really is. I haven’t noticed it as much as I was but I am keeping an eye out. I may order another Pi2 and see if it has the same problems.
@N456TS - Actually never overclocked my B+ so that wouldn’t be the issue but good information to know.
@N456TS and TomMuc - I actually had new install for the Pi2 on a new SD card so that eliminates that possibility but I am thinking of doing another install on the SD card and see if maybe it is a glitch with the install I have currently. My CPU usage on the B+ stayed around 40% and the Pi2 stays around 25% with the same software setup.
Thanks again for all the helpful ideas. I will report back if I get different results after a fresh install.
dump1090-mutability colors the plane icons by altitude, so mlat doesn’t show up there.
I took a quick look and there is nothing unusual on the server side, there are just not enough nearby receivers to support mlat. There are 3 receivers including yours in your area, and you do seem to synchronize with the others OK from time to time, but 3 is not enough for mlat results - minimum is 4.
Alright thanks then. Nothing to worry about
edit 29/09/2015: somehow after the release 2.1.3 have been put live, and before I did the update myself, my usual MLAT error message disappeared from the flightaware stats home page.
Now I myself also run 2.1.3 as well.
Having trouble with piaware 2.1-3
This was working yesterday after upgrade to 2.1-3. Today MLAT not working…
[2015-10-05 22:12 MDT] multilateration support enabled (use piaware-config to disable)
[2015-10-05 22:12 MDT] multilateration data requested, enabling mlat client
[2015-10-05 22:12 MDT] Starting multilateration client: /usr/lib/piaware/helpers/fa-mlat-client --input-connect localhost:30005 --results beast,connect,localhost:30004 --udp-transport 70.42.6.198:9076:3526630675
[2015-10-05 22:12 MDT] mlat(2608): fa-mlat-client 0.2.4 starting up
[2015-10-05 22:12 MDT] mlat(2608): Using UDP transport to 70.42.6.198:9076
[2015-10-05 22:12 MDT] mlat(2608): Input connected to localhost:30005
[2015-10-05 22:12 MDT] mlat(2608): Beast-format results connection with localhost:30004: [Errno 111] Connection refused
[2015-10-05 22:13 MDT] 50 msgs recv’d from dump1090-mutab; 50 msgs sent to FlightAware
[2015-10-05 22:13 MDT] mlat(2608): Beast-format results connection with localhost:30004: [Errno 111] Connection refused
[2015-10-05 22:13 MDT] mlat(2608): Beast-format results connection with localhost:30004: [Errno 111] Connection refused
pi@na5ss-1 ~ $ sudo piaware-status
dump1090 is not running.
faup1090 is running.
piaware is running.
dump1090-mutab is listening for connections on port 30005.
faup1090 is connected to port 30005.
piaware is connected to FlightAware.
dump1090-mutab is producing data on port 30005.
pi@na5ss-1 ~ $ netstat --program --tcp --wide --all --numeric
(No info could be read for “-p”: geteuid()=1000 but you should be root.)
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:30104 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:30001 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:10001 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:30002 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:30003 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:30005 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56299 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56351 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56339 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56354 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56335 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56313 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56310 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56296 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56349 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56329 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56315 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56301 TIME_WAIT -
tcp 0 0 127.0.0.1:30005 127.0.0.1:53177 ESTABLISHED -
tcp 0 0 192.168.0.56:39721 70.42.6.198:1200 ESTABLISHED -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56293 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56355 TIME_WAIT -
tcp 0 0 127.0.0.1:30005 127.0.0.1:53178 ESTABLISHED -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56342 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56303 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56288 TIME_WAIT -
tcp 0 0 127.0.0.1:80 127.0.0.1:42297 TIME_WAIT -
tcp 0 0 127.0.0.1:80 127.0.0.1:42299 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56285 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56309 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56318 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56295 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56307 TIME_WAIT -
tcp 0 0 127.0.0.1:80 127.0.0.1:42298 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56322 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56346 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56298 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56326 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56302 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56331 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56291 TIME_WAIT -
tcp 0 0 127.0.0.1:80 127.0.0.1:42296 TIME_WAIT -
tcp 0 0 127.0.0.1:53177 127.0.0.1:30005 ESTABLISHED -
tcp 0 2696 192.168.0.56:22 192.168.0.53:55109 ESTABLISHED -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56337 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56320 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56344 TIME_WAIT -
tcp 0 0 127.0.0.1:53178 127.0.0.1:30005 ESTABLISHED -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56333 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56305 TIME_WAIT -
tcp 0 0 192.168.0.56:8080 192.168.0.53:56323 TIME_WAIT -
I have entered the following command lines yesterday and things worked fine. But today I enter them after a reboot and get the error above.:
$ sudo piaware-config -mlatResultsFormat beast,connect,localhost:30004
$ sudo service piaware restart
I modified /etc/default/dump1090-mutability.
Am I doing anything wrong? Did something get corrupted? Any help to resolve this would be appreciated.
Thanks,
Mike
I think there is a mismatch of the ports used for sending mlat messages back to dump1090.
You configured dump1090-mutability to accept messages on port 30104 but you are instructing the mlat client to send them on 30004.
Best option is to reset the mlat client to use the new default value of 30104.
Not 100% sure if this is correct, but try first:
$ sudo piaware-config -mlatResultsFormat default
$ sudo service piaware restart
Alternatively, specify the port directly:
$ sudo piaware-config -mlatResultsFormatbeast,connect,localhost:30104
$ sudo service piaware restart
GREAT!
$ sudo piaware-config -mlatResultsFormat default
$ sudo service piaware restart
Resetting did the trick. No more errors.
Thanks,
Mike
Is there something going on with FA?
I’m sending MLAT:
[2015-10-08 10:33 EDT] mlat(2494): Aircraft: 37 of 40 Mode S, 14 of 17 ADS-B used
[2015-10-08 10:33 EDT] 7533 msgs recv’d from dump1090-mutab (575 in last 5m); 7533 msgs sent to FlightAware
[2015-10-08 10:38 EDT] 8193 msgs recv’d from dump1090-mutab (660 in last 5m); 8193 msgs sent to FlightAware
[2015-10-08 10:43 EDT] 8749 msgs recv’d from dump1090-mutab (556 in last 5m); 8749 msgs sent to FlightAware
[2015-10-08 10:48 EDT] mlat(2494): Receiver status: connected
[2015-10-08 10:48 EDT] mlat(2494): Server status: synchronized with 12 nearby receivers
[2015-10-08 10:48 EDT] mlat(2494): Receiver: 220.3 msg/s received 3.7kB/s from receiver
[2015-10-08 10:48 EDT] mlat(2494): Server: 0.0 kB/s from server 0.0kB/s TCP to server 2.3kB/s UDP to server
[2015-10-08 10:48 EDT] mlat(2494): Aircraft: 42 of 53 Mode S, 11 of 12 ADS-B used
[2015-10-08 10:48 EDT] 9280 msgs recv’d from dump1090-mutab (531 in last 5m); 9280 msgs sent to FlightAware
But I don’t see any my local display
MLATs have disappeared. KIAD and KFLL. Something amiss at the servers? Joe K4AA
UPDATE: All better now.
Yeah, some internal network problems again. Working on it.
Just got MLAT going yesterday after finally getting around to putting a good antenna on the roof and adding a filter as well. It seems to do a good job for the most part but I do see the occasional track with instantaneous changes in position of 5-10 miles or even more in some cases. My best guess is that this is caused by MLAT enabled sites with incorrect positions being used for the location calculations. This brings up a few questions:
- I have a few Pis with GPS hats, is it possible to feed this location data to FlightAware along with a delta for the receiving antenna height? This would be a nice option.
- I’ve noticed from some of my early experiments that indoor antennas have very directional coverage and that the algorithms used to estimate the receiver location can be thrown off wildly by this. I’ve seen errors of 50+ miles going by what is dished out automatically. As the number of MLAT enabled receivers increases, I think it would be a good idea to consider only allowing data from receivers with manually configured locations to be used.
- One option would be for FA to randomly pick a certain number of flights each day with ADS-B info and request MLAT info from all nearby receivers and keep statistics on this. Any receivers consistently providing bad info should be disallowed from participation.
Here is an example of a jump of about 10 miles:
http://i20.photobucket.com/albums/b241/tdasher/Track_Jump.jpg
That is probably a solution-geometry problem, not a location-accuracy problem. There are already mechanisms in place that discard data from receivers that aren’t producing useful data. There is already a requirement that receivers need a manually-entered location before being used for mlat.
I’ve just got back from travelling and updated my pi with the latest piaware and dump1090-mutability (from git). I have the ports on the mlat client and dump1090 configured to receive the results. MLAT results appear to be shown in dump1090, but they are not differentiated with blue highlighting. Is that something that is only implemented in the piaware fork, or is there something amiss?
dump1090-mutability should highlight mlat-derived positions in blue on the righthand table, but it doesn’t display them differently on the main map at the moment.
It’ll also tell you it’s a mlat position in the plane detail when you select a plane.