Just since today my tracks in dump1090-muta and VRS are all messed up. I’m showing VRS here because I can show all the tracks at once, but they look the same in dump using lighttpd. Do I have something misconfigured? This is VRS v2.1 - not the new preview version.
I’d guess MLAT too, ours seem to have straight smooth lines though - but that could be because we’re swamped with feeders and the positions can be average / rogues eliminated more easily.
Yep, that looks like mlat results. It’s not an exact science 
You will probably find that some areas have better or worse tracks than others - it’s quite dependent on the exact receivers used. It should get a little better as the server side gets some improvements to weed out receivers that have unstable clocks or incorrect positions configured.
Mine looks like that too. I have planes landing 5 miles from the airport in the middle of a shopping center and others suddenly shooting off to another track.
Kind of a mess.
Reminds me of an old Far-Side cartoon where the pilots were telling the passengers they were going to encounter turbulence and then making big moves on the yolk. LOL Must be ALOT of turbulence today. 
Cheers!
LitterBug
I suspected mlat, but I didn’t want to jump to the conclusion. mlat’s the newest thing and I didn’t want to blame it without confirmation. OK, let’s hope it gets more exact. 
Thinking about it, there will be a many people running Pi’s that - bluntly - don’t know what they’re doing, don’t know about the MLAT stuff, have never corrected the antenna co-ordinates on the system, etc
They’ve got a Pi, a dongle and - whey-hey - they can see planes on the screen. Where they’re located has been calculated by FA. Now they’ve received an auto-update that has enabled MLAT on their rig.
I just wonder if it’s worth a having an e-mailshot to let everyone know about the importance of
Does the new preview version of VRS smooth things out? I haven’t had a chance to install it yet.
Surely it shouldn’t? I’d have thought it would display what was recieved.
Yep. Currently you have to manually set the receiver location before mlat is enabled, which helps a little. However I need to work on detecting receivers that are producing inconsistent data. The nature of how messages are paired up means that receivers that are wildly wrong just will never pair up so that doesn’t hurt, but receivers that are slightly wrong (say, 5km out) will produce results that are close enough that they can interfere with correct receivers.
Once that’s in place there’s lots of things that can be done - obvious one is to exclude bad receivers from contributing to results, but also have it appear on the stats page, trigger mail, etc.
No, it is exactly the same with the preview version since it is just reporting the feed. But hey, at least we see a lot more positions, even if they are a little erratic.
Andy
How about comparing where they see a full ADSB plane with where it would be on the MLAT curve for that reciever.
It would be sort of cute to calculate the receiver location using a reverse MLAT type calculation from a set of known aircraft positions.
It’s hard to identify which receiver is wrong in this case. You could maybe look at the residual errors in the mlat solution, but it’s not entirely obvious and would probably only work if you had a lot of extra receivers, in which case the rogue receiver actually doesn’t matter so much anyway.
It would be sort of cute to calculate the receiver location using a reverse MLAT type calculation from a set of known aircraft positions.
This is basically GPS But the issue is that you need to know both the time of transmission and the location of the transmitter. You know this in GPS (position from the satellite ephemeris, time is encoded in the message) but it is harder in the ADS-B case because you don’t know the transmission time. You would have to use a set of positions which were all seen by a reference receiver which has a known-good location and use that to determine the intervals between transmission. And you need a set of aircraft that surround the target receiver to get a good result. It all gets a bit complicated.
The current approach I am looking at is to look for large (>5us?) steps in clock sync and sectorize the ADS-B aircraft locations that triggered them. If a receiver has an incorrect location it should tend to generate sync errors with a sign that depends on which side of the receiver the aircraft is. e.g. if the claimed receiver location is, say, east of the true location, then the sync calculation will use a signal travel time that is too small for aircraft to the east of the receiver and too large for aircraft to the west, which turns into corresponding sync errors.
So I understand this completely, when an aircraft has a jagged trail, is that aircraft transmitting mlat only, or do they also transmit their position using mode-s as well?
Everything you see is sending Mode S. Some are also sending the extended squitter messages (a type of mode S message) that carry ADS-B position reports.
Multilateration is only applied to aircraft that are not sending ADS-B position reports. If you turned off mlat you wouldn’t see positions for the jagged-track aircraft at all.
OK, I understand. That would explain why I’m seeing a lot more locations today. That is, a greater proportion of the the total aircraft have locations.
Nice to see some Mlat in the US. Feeding my VRS for over 12 hours now and not one plane has shown. Thinking of turning mine off until it is needed. I guess all the feeders in my area haven’t set their antenna. It does say enabled MLAT on their page but I guess it throws them out. Wish you could message these people some how.
How will you tell when it’s needed?
I wonder if your use of modes2mixer is somehow breaking things. There’s no obvious problems I can see with your site other than you just have no clock synchronization with any other receiver. But that may just be due to a lack of overlap. Can you try a vanilla setup?
It may be a bit more glitchy than normal at the moment - I am working on some server changes.
