Aircraft position jumping around on radar map?

Ever since about 2-3 months ago (but after Piaware 3.0 was released) I’ve noticed that a lot of my aircraft positions are very flakey on my radar map. Any idea why this is happening? It’s very annoying. I’m seeing this happen with multiple a/c on my radar – it’s not a random event – it happens all the time.

For the example a/c below, I’m literally line-of-sight to that aircraft. I’m on a hilltop @ ~350ft and with my high antenna location (well above roofline of house) this shouldn’t be happening.

Here’s an example of what I’m seeing:

It’s due to MLAT. IMO, there are not enough receivers in your area to get a “good” fix on the planes. There is probably the minimum number of receivers to be giving you a location, but then when it “mixes” with the other MLAT reporting positions, it jumps around.

I could be wrong tho. :slight_smile:

This isn’t a problem with too few receivers but the output looks identical to having the minimum number of receivers.

There are 66 synched receivers in this area.
You can see the number of synced sites on their ADSB stats page:
Multilateration (MLAT): Supported / Enabled (synchronized with 66 nearby receivers)

This looks like the data is bouncing off two different sets of MLAT solutions. The MLAT system doesn’t use all 66 receivers to do MLAT but a picks a subset of the data for a time period. The next time period another subset will be group together. It looks like one of the subset is getting some bad timing information and one subset is doing much better.

A little more technical information. We use sub microsecond timing for MLAT. This is a very large distance error compared to nano second timing for GPS or sub nano second timing in the new GPS+ systems. You can see what i mean by how fast radio waves travel in that time period. As the clocks get better the error range get much better. Some new GPS+ systems are able to get down to inches and fractions of an inch.
google.com/#q=speed+of+ligh … icrosecond
google.com/#q=speed+of+light+*+1+nanosecond

The FA prostick and a bunch of premium dongles use $1 clock components compared to the $0.20 clocks found in generic dongles. The premium dongles should all give good microsecond timing under most temperature conditions.

The generics dongles are mostly good at microsecond timing. We did find a bunch with tens of microsecond to hundreds of microseconds under very bad temperature conditions.
Timing issue are detectable through software so this problem should be fixable.

david.baker,
re: “A little more technical information. We use sub microsecond timing for MLAT. This is a very large distance error compared to nano second timing for GPS.”
Thank you for that explanation.
Has anyone over there seen one of Grace Hopper’s ‘nano seconds’?

[quote=“david.baker”]The generics dongles are mostly good at microsecond timing. We did find a bunch with tens of microsecond to hundreds of microseconds under very bad temperature conditions. Timing issue are detectable through software so this problem should be fixable.
[/quote]

Well I’m using the Flightaware Pro Stick on my Pi 3 and have the Pro Stick Plus on the way. I also use the Uputronics ADS-S filter and amp in my antenna chain. I checked my PiAware OS clock is perfectly sync’d to NIST server (and that matches my Windows machine precisely.)

I would presume that PiAware 3.10 has built-in software to make sure the clock is sync’d regularly to a time server?

Also, if a station is out-of-sync then wouldn’t the FA servers ignore its information after X time period?

Well I’m using the Flightaware Pro Stick on my Pi 3 and have the Pro Stick Plus on the way. I also use the Uputronics ADS-S filter and amp in my antenna chain. I checked my PiAware OS clock is perfectly sync’d to NIST server (and that matches my Windows machine precisely.)

I would presume that PiAware 3.10 has built-in software to make sure the clock is sync’d regularly to a time server?

Also, if a station is out-of-sync then wouldn’t the FA servers ignore its information after X time period?
[/quote]

The timing is from a clock in the dongle(as stated by David above). It has nothing to do with local GPS time on the RPI. The USB bus is too variable to be of use anyway. The ethernet port is also done over the same USB bus so would also be not great for accurate timing.
The devices that provide GPS time stamps are generally FPGAs and send the GPS time stamp with the ADS-B data over the USB bus.

David,
Maybe you could add some details as to how MLAT works (what messages it uses for timing and the local clock in most dongles) on one of the FAQ web pages. I am sure that a lot of users would like to know the ins and outs of MLAT.

Yes, I’m familiar with how SDRs work.

Well, then, how else would the FA server validate packets coming from individual stations? There has to something to keep the data in sync…? Which at least for these latest versions isn’t happening. There’s no “timestamp” data in an ADS-B packet frame… (unless the GPS position information contains that info) – so the RPI has to be sending some kind of time data to the FA server.

The details are here github.com/mutability/mlat-server ,
“It uses ADS-B aircraft that are transmitting DF17 extended squitter position messages as reference beacons and uses the relative arrival times of those messages to model the clock characteristics of each receiver.”

Basically, you have two known locations (Aircraft and RPI, and the distance between them can be calculated),
From there you can work out a relative value for time. This value can be used with other RPIs for position calculations for non position based transponders.

It would be better(more accurate) if there were GPS based units, like radarcapes(<20 in USA, <7 in Aus, <40 in Europe) and some flightfeeders, in the area, but they are not necessary. Even more accurate dongle clocks would help with accuracy.

Clocks are actually very complicated when you are trying to get them synced. I am not sure how in-depth this can go on a forums but here are the basics.

  1. Clocks have a frequency they clock at (think of a tick/tock as one cycle). So a prostick is clocking at 2.4MHz will go tick/tock 2.4 million times a second. Some clocks have very accurate ticks and some are designed for very accurate ticks and tocks. Atomic clocks on the GPS system clocks at 9 billion times a second and have super accurate tick/tocks.

  2. Clocks have an accuracy, drift, and offset values. The prostick is designed for 2.4MHz clocking with a ±2 cycle drift. This means the clock can add or subtract 1-2 tick/tocks every seconds. Or in terms of cycles, instead of getting 2,400,000 cycles you might have 2,400,002 cycles. After a day this small error can add up. Normal generic RTL dongles are usually around ± 30 cycles drift. We have seen some generic RTL dongles with over ±100 cycles of drift.

Clocks that deviate less can get very expensive.

  1. Syncing clocks and master clocks are the key to modern timing. The idea is that instead of putting in multi million dollar clocks into a system we can sync all the cheap clocks to the multi million dollar clocks. These multi million dollar clocks are in the GPS satellites! Clocks that get their time directly from the GPS are called stratum 1 system. Clocks that get their time from a stratus 1 system are called stratus 2 system… etc.

Cellphones are a great example. The cell tower get their time directly from the GPS satellites. They then send the tower time to the cellphone (the sync part). Cellphone are stratum 2 timing devices!

Since cellphone talk to the tower a lot they are able to sync the clock back to the very very accurate GPS time. Every time they sync back to the tower the timing error is reset back to 0. You do enough syncs and your timing is practically as good as a multimillion dollar clock.

There are many ways to do the syncing part. NTP is one way to sync clocks. GPS is another way to sync. FA MLAT system is another way sync. There are some advantages and disadvantages to how you sync but this post is also very long.

As jon says it uses ADS-B equipped aircraft as a reference beacon. The start of each received message is timestamped by counting samples since the receiver started. The exact frequency, and the zero offset, of those timestamps will vary from receiver to receiver. The relative arrival times of ADS-B position messages (which have a known transmission location) are used to work out the relative frequency and offset for pairs of receivers; then you can use those parameters to work out the TDOA for non-ADS-B messages that you want to multilaterate.

The core of it is here: https://github.com/mutability/mlat-server/blob/master/mlat/server/clocksync.py

Re the original post, that’s either poor geometry / too few receivers, or you are feeding two different mlat sources (FA and something else) into your map.

How would I check this?

NVM, I’m just going to reimage…

Interesting. A rebuild of my Piaware seems to have fixed the problem. I remember a couple of upgrades returning some error messages but nothing that prevented the Piaware from running. I guess it wasn’t running very well.

[quote=“cnick6”]

It would be something that you explicitly set up, it would not happen with an unmodified piaware image but if you are feeding third party sites that also provide their own mlat results then it could be an issue.