Archived - Beta test MLAT software for Raspberry Pi

[Kpin]

Mike

If a cluster of RPi MLAT receivers were placed in an optimal configuration around an airport, how low would you expect aircraft to be seen? And what would an optimal configuration be in terms of distance between receivers?

[Patrick Reeves]

Mike

If a cluster of RPi MLAT receivers were placed in an optimal configuration around an airport, how low would you expect aircraft to be seen? And what would an optimal configuration be in terms of distance between receivers?

I'm going to take a stab at this-

Clock resolution is 12MHz. Speed of light is 300,000km/sec. So the theoretical limit would call for at least 25 meters of separation. 2-3 km of separation and good line of sight by all 4 receivers should give decent ground coverage, IMO. MLAT coverage at LAX is good down to around 300 meters alt., but due to tall buildings and uneven terrain MLAT ground isn't possible. It would be neat if a couple of rpi Mlat T- feeders could place 4 receivers around the perimeter of a busy airport.

[obj]

I'm going to take a stab at this-

Clock resolution is 12MHz. Speed of light is 300,000km/sec. So the theoretical limit would call for at least 25 meters of separation. 2-3 km of separation and good line of sight by all 4 receivers should give decent ground coverage, IMO. MLAT coverage at LAX is good down to around 300 meters alt., but due to tall buildings and uneven terrain MLAT ground isn't possible. It would be neat if a couple of rpi Mlat T- feeders could place 4 receivers around the perimeter of a busy airport.

You don't get anywhere near 12MHz with a Pi/dongle, unfortunately.

mlat-server (here: https://github.com/mutability/mlat-server) gets about 0.5us-1us synchronization between dongles, so somewhere around 150-300m pseudorange error. The actual position error in the result is maybe twice that with good receiver geometry.

FR24's implementation appears to rely on the system clock which I expect will be a lot worse than that (10km quoted above?)

[Patrick Reeves]

FR24's implementation appears to rely on the system clock which I expect will be a lot worse than that (10km quoted above?)

Thanks for the feedback. I read here (somewhere) that the F- boxes have 12MHz res.
us- res would not treat ground traffic very well.

[helios]

There's not only the uncertainity of the timer but also a delay on the receiver-usb-cpu path, probably with jitter.
I'm amazed that it's working at all.

Having a GPS on the RasPi probably wouldn't help much. The only way the accuracy could be enhanced using GPS and RTLSDR, would be mixing the PPS signal of a GPS-receiver to the RF-Input of the receiver and changing the decoder that it's counting the time from the PPS.
But it would require a Hardware (and software) modification. Though this could be done very affordable, it probably would prevent a wide spread in contrast to the pure software solution.

[Mike]

Hi, a few questions:

1. Im using a Raspi 1 atm. will it benefit when using a Raspi 2 instead? (CPU usage is always about 50%, there is no multicore support?)
2. Some of you are using GPS as timesource, will FR24 benefit from this? What kind of GPS do you use?
3. Are there any "tweaks" to the software to get better/more data/range?

My range seems to be quite good, atm. since im only indoor with a simple antenne, max. Distance 52nm so far

1. Probably not but I'm not the right person to answer this.
2. No, if you connect a GPS we will not use the data. The processing delay will be too long to have good quality data.
3. As mentioned in other threads our focus is data quality and not a couple extra miles with potential bad data.

[Mike]

Mike

If a cluster of RPi MLAT receivers were placed in an optimal configuration around an airport, how low would you expect aircraft to be seen? And what would an optimal configuration be in terms of distance between receivers?

We don't really know, but probably a couple of kilometers apart from each other. My impression is that we get best/most data within the boundaries of the receivers so with bigger distance between we get better coverage area. A good example is MLAT coverage in different islands, for example Iceland, Taiwan, Madeira where we get quite limited MLAT coverage, especially outside of the islands, although we have many receivers (up to 15-20 receivers per island).

[obj]

There's not only the uncertainity of the timer but also a delay on the receiver-usb-cpu path, probably with jitter.
I'm amazed that it's working at all.

Having a GPS on the RasPi probably wouldn't help much. The only way the accuracy could be enhanced using GPS and RTLSDR, would be mixing the PPS signal of a GPS-receiver to the RF-Input of the receiver and changing the decoder that it's counting the time from the PPS.
But it would require a Hardware (and software) modification. Though this could be done very affordable, it probably would prevent a wide spread in contrast to the pure software solution.

I, too, am somewhat amazed that using the system clock works at all!

mlat-server avoids the system clock / USB jitter problems by using ADS-B equipped aircraft as reference beacons for synchronization; then you just have to count samples, and the RTLSDR dongle frequency is stable enough over short periods.

[helios]

a comment to the developers:
You may want to consider disabling logging (or placing it on a tmpfs) by default in the final release, as frequent writing may wear out the flash memory cells on sd-cards. Though it is only a small amount of data, it has to rewrite a whole block each time.
I was choosing "no logging" in the setup, but it was gently ignored

[mrcarlos]

updated sucess works fine congratulations to developers

[equi]

running smooth on my BananaPi

minion@banana ~ # sudo service fr24feed status
[ ok ] FR24 Feeder/Decoder Process: running.
[ ok ] FR24 Stats Timestamp: 2015-07-11 15:24:48.
[ ok ] FR24 Link: connected [UDP].
[ ok ] FR24 Radar: T-EDDE7.
[ ok ] FR24 Tracked AC: 11.
[ ok ] Receiver: connected (3305 MSGS/0 SYNC).
[ ok ] FR24 MLAT: ok [UDP].
[ ok ] FR24 MLAT AC seen: 11.

Btw. how can i verify if my long. and lat. is correct entered ?

[Dundee]

running smooth on my BananaPi



Btw. how can i verify if my long. and lat. is correct entered ?

Google Map XD
or you mean to check whether the value is correctly entered?
You may access fr24feed.log...
everything is there...

[diazepam]

Hi

Today I reactivated my old receiver, new radar code T-SBCO1.

But in fr24feed.log:

2015-07-11 15:37:36 | [feed][i]sent 1 AC in 1 packet
2015-07-11 15:37:41 | [feed][i]sent 1 AC in 1 packet
2015-07-11 15:37:43 | [mlat][i]Registering MLAT station: FAILURE
2015-07-11 15:37:44 | [mlat][i]Configuring UDP connection udp://mlat-4.fr24.com:19788
2015-07-11 15:37:44 | [mlat][i]Registering MLAT station


And status of service:

[ ok ] FR24 Feeder/Decoder Process: running.
[ ok ] FR24 Stats Timestamp: 2015-07-11 15:40:23.
[ ok ] FR24 Link: connected [UDP].
[ ok ] FR24 Radar: T-SBCO1.
[ ok ] FR24 Tracked AC: 3.
[ ok ] Receiver: connected (2663 MSGS/0 SYNC).
[FAIL] FR24 MLAT: not running ... failed!


Anybody can help me?

Thanks!

[equi]

found it, but it seems that it changed the coordinates for some reason. Any idea how I can fix that (without running the signup wizard again) ?

[Kpin]

We don't really know, but probably a couple of kilometers apart from each other. My impression is that we get best/most data within the boundaries of the receivers so with bigger distance between we get better coverage area. A good example is MLAT coverage in different islands, for example Iceland, Taiwan, Madeira where we get quite limited MLAT coverage, especially outside of the islands, although we have many receivers (up to 15-20 receivers per island).

Without aiming at changing the subject frem RPi/MLAT to MLAT, I found this document which is probably not unfamiliar to you at FR24:
https://www.eurocontrol.int/sites/de...ion-200508.pdf

It says that there should be at least some quality tracking outside the receiver perimeter, and also that for enroute tracking the receivers can and should be spaced wider