Announcement

Collapse
No announcement yet.

Archived - Beta test MLAT software for Raspberry Pi

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    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?

    Comment


    • #62
      Originally posted by Kpin View Post
      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.
      F-KDAG1

      Comment


      • #63
        Originally posted by Patrick Reeves View Post
        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?)

        Comment


        • #64
          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.
          F-KDAG1

          Comment


          • #65
            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.

            Comment


            • #66
              Originally posted by Astrofreak85 View Post
              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.

              Comment


              • #67
                Originally posted by Kpin View Post
                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).

                Comment


                • #68
                  Originally posted by helios View Post
                  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.

                  Comment


                  • #69
                    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

                    Comment


                    • #70
                      updated sucess works fine congratulations to developers

                      Comment


                      • #71
                        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 ?
                        Last edited by equi; 2015-07-11, 15:28.
                        Regards,
                        T-EDDE7

                        Debian 8 Server | jetvision ADS-B USB Dongle | ADS-B Collinear Antenna
                        Banana Pi | Mystique SDR R820T2 | stock Antenna

                        Comment


                        • #72
                          Originally posted by equi View Post
                          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...
                          Last edited by Dundee; 2015-07-11, 15:32.
                          T-VHST9: http://vhst9.hopto.org/
                          (24/7)

                          Comment


                          • #73
                            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!

                            Comment


                            • #74
                              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) ?
                              Regards,
                              T-EDDE7

                              Debian 8 Server | jetvision ADS-B USB Dongle | ADS-B Collinear Antenna
                              Banana Pi | Mystique SDR R820T2 | stock Antenna

                              Comment


                              • #75
                                Originally posted by Mike View Post
                                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
                                Last edited by Kpin; 2015-07-11, 18:01.

                                Comment

                                Working...
                                X