I couldn’t wait any longer and changed to dump-mut 1.15-dev and piaware 2.1-1. At 11 PM my load average is consistently over 1. I’m hovering around 1.2. I’m already overclocked by one setting (800mhz?). I can’t image what daytime traffic will do. Messages/minute at night are what they typically are during peak daytime. I guess I’ll try a little higher overclock. I do have a Pi2 I can swap out.
obj,
Is there a way to add a timer like is used for the ADSB aircraft to remove the MLAT aircraft from the map when no position change has been received for x-seconds? I seem to be at the end of the line and I’ll see aircraft come toward me then stay in place til they are out of my range.
Thanks, Mark
It’s a little tricky to work out exactly what to do there. Dump1090 hides aircraft when it has not seen messages from them at all for 60 secs. But for mlat aircraft it is common to stop receiving positions because it has moved out of mlat coverage (often when descending, receivers start losing contact) but you still hear the aircraft’s direct messages so it doesn’t expire. This is actually the same as adsb, you just notice it more often with mlat because you tend to lose both adsb messages and all other messages at about the same time.
I posted this in another thread, but it’s more appropriate here, I think.
The new PlaneFinder client is also supporting mlat now. forum.planefinder.net/threads/pl … -2080.294/
It only does mlat if you have a Radarcape (that’s quite a bit simpler to support as it does GPS timestamps on messages).
So, if you want to know about the quality of the MLAT-results, just call the guys from the NATO and tell them to do a few perfect circles for you… 
Germany, black forest, northern part:
Kabuse
That’s cool! Nice catch. 
Sometimes I had 400-500 positions per minute. Not too bad I think and the coverage should be better now I guess. Good work!
Hi obj,
Not sure if it’s related but after you made this change the next morning my Pi would hang when attempting to ssh into it, I reset it last night and it worked overnight and I was able to maintain an ssh connection to watch the load go up to 5.55 this morning (getting close to peak time for my area), I did an “ls” in one of the folders and my SSH session just hung, I can see it’s still outputting results to the web interface but it looks to have stopped pushing data to FA and I still can’t ssh into it.
Do you think excessive load would prevent SSH from establishing a connection as I am running dump1090 in “aggressive” mode combined with the MLAT overhead? or does it sound more like I’ve got a shagged SD card?
cheers izy
PS I’ve been running aggressive mode since installing the unit some 180 days ago and it’s never locked up like this before.
Sounds like the perennial bad hardware or insufficient power problems to me. If you have marginal power then yes, more CPU can make it fail.
I would suggest turning off --aggressive (for data quality reasons, not CPU load)
Thanks obj, I’ll reset it tonight and turn off aggressive and see how it goes, I’ve got 3 x Pi 2 B’s coming, 2 for the new feeder locations and I’ll use the other one to upgrade this existing Pi B+, I think the Pi B+ will do nicely with a GPS hat as an NTP server!
Do you have a recommended list of switches to use when running dump1090?
Hopefully a few more stations will come on line near me to keep them moving past me. I see the most toward my northwest as they travel between the Atlanta, Ga / Charlotte, NC area and most of them move til I stop receiving them. Thanks
I watched one of those last night. In the beginning, I only had direct messages from this plane. I presumed that I was coming in from the Atlantic and not enough other stations were receiving messages to provide an MLAT position. As it came nearer to the cost, MLAT positions started to come in and the plane appeared on the map. This continued for some time until MLAT coverage was lost again. However, I was still receiving direct messages for another few minutes. With the plane selected, it showed me an unchanging MLAT-derived position (i.e. last known position) together with a counter indicating the age of that position.
My suggestion here is that when the age of the last know position reaches 60 seconds, the plane is removed from the map but kept in the list until it does not receive any messages at all and then ages out in the normal way.
Regards,
Marcus
How about removing the MLAT info at 60 seconds so they just appear as white in the table. (or is that what you meant?)
Yes I guess that’s what I meant: remove the MLAT info after 60 seconds, revert to White in the table AND remove icon from the map.
How do i upgrade my dum1090-mutability to 1.15, so i have a different color for MLAT Positions? Thanks!
As far as I know, there is no packaged version available. So you will have to build it yourself. Instructions here:
post177419.html#p177419
obj has great instructions here to use his repo to install the pre built packages which works very well
ads-b-flight-tracking-f21/raspbian-ubuntu-packages-for-dump1090-mutability-available-t19619.html
I have a question. I know this is probably a dumb question. How do I know or check if Mlat is working? I am running a Pi with Dump1090-Mut. When I bring up the map to see the dump running on the right side, it says V1.14.
Thanks.