Page 34 of 91 FirstFirst ... 2432333435364484 ... LastLast
Results 331 to 340 of 901

Thread: Archived - Beta test MLAT software for Raspberry Pi

  1. #331
    Purser
    Join Date
    Jan 2015
    Location
    Kallangur, Brisbane
    Posts
    168
    Quote Originally Posted by vinnyspb View Post
    Hi guys,

    We're pleased to announce new beta version of the feeder software (1.0.14-9) that is no longer bound to our own dump1090 build.
    Included dump1090 is now Malcolm Robb's fork and I would kindly ask you to also test how it works with other forks that you may wish to use and provide a feedback.

    Thanks,
    Flightradar24 team
    Very nicely done vinny!!! I hadn't followed this thread for a few days, it's nice to get pleasant surprise when I jump back in! I've updated, turned mlat back on.. Using mutability as I was previously, and it seems to be working just fine from what I can see.

    Any chance in the future that we will get mlat position feedback so we can view via a basestation/beast network port (to connect with VRS)? That would be awesome as well.. Either way, happy to feed Mode-S data now as it doesn't increase load like it did before.

    Good work!!! Thanks
    T-YBBN50 - Kallangur, QLD, Australia

  2. #332
    Purser Tviki's Avatar
    Join Date
    Feb 2012
    Location
    Estonia, Johvi
    Posts
    121
    Online again!!! Just installed Malcolm Robb dump1090
    F-EETU1, F-EETU5, T-EETU1

  3. #333
    Passenger
    Join Date
    Oct 2014
    Posts
    42
    Is mlat working using other feeder rather than the default one like mutability one or am I just feeding mode s?

  4. #334
    Passenger
    Join Date
    Nov 2014
    Posts
    20
    Quote Originally Posted by giacomo892 View Post
    Is mlat working using other feeder rather than the default one like mutability one or am I just feeding mode s?
    Yes.. this question!

  5. #335
    Passenger
    Join Date
    Nov 2014
    Posts
    20
    Also, can anyone help me with setting up my /etc/fr24feed.ini file? I'm mainly just a FA feeder.
    I already have 3 instances of dump1090-mulitibilty running on a RPi2. All have the --mlat enabled.
    I would like to feed the beast output from all three dump1090 instances(or maybe just the output of the main dump1090 that others feed??) to fr24feed (not using any dongles directly). I am currently feeding the two dongles to the main feed using nc, which works. Just not sure what reciever type or how to enable fr24feed to listen on a nonstandard port for beast input in the fr24feed.ini file.

    Here are my current dump-1090 settings for the three instances running, with the last one being the master version getting data from the first two:

    Code:
    dump1090-mutability --mlat --quiet --net --interactive-ttl 300 --modeac --lat <edited> --lon <edited> --phase-enhance --gain -10 --ppm 26 --device-index 1 --net-bo-port 31007 --net-bi-port 0 --net-ro-port 0 --net-ri-port 0 --net-sbs-port 0 --net-http-port 0 --net-fatsv-port 0

    Code:
    dump1090-mutability --mlat --quiet --net --interactive-ttl 300 --modeac --lat <edited> --lon <edited> --phase-enhance --gain -10 --ppm 30.920 --device-index 2 --net-bo-port 31006 --net-bi-port 0 --net-ro-port 0 --net-ri-port 0 --net-sbs-port 0 --net-http-port 0 --net-fatsv-port 0
    Code:
    # dump1090-mutability configuration file
    # This is a POSIX shell fragment.
    # You can edit this file directly, or use
    # "dpkg-reconfigure dump1090-mutability"
    
    # Set to "yes" to start dump1090 on boot.
    START_DUMP1090="yes"
    
    # User to run dump1090 as.
    DUMP1090_USER="dump1090"
    
    # Logfile to log to
    LOGFILE="/var/log/dump1090-mutability.log"
    
    #
    # Receiver options
    #
    
    # RTLSDR device index or serial number to use
    # If set to "none", dump1090 will be started in --net-only mode
    DEVICE=""
    
    # RTLSDR gain in dB.
    # If set to "max" (the default) the maximum supported gain is used.
    # If set to "agc", the tuner AGC is used to set the gain.
    GAIN="max"
    
    # RTLSDR frequency correction in PPM
    PPM="0"
    
    # If yes, enable sampling at 2.4MHz. Otherwise, 2.0MHz is used.
    OVERSAMPLE="yes"
    
    # If yes, enables phase-enhancement of messages
    PHASE_ENHANCE="yes"
    
    #
    # Decoding options
    #
    
    # If yes, fixes messages with correctable CRC errors.
    FIX_CRC="yes"
    
    # If yes, enables aggressive fixes to damaged messages.
    # Use with caution - it can increase the rate of undetected errors.
    AGGRESSIVE="no"
    
    # If set, supplies a reference location for local position decoding.
    LAT="<edited>"
    LON="<edited>"
    
    # If set, provides the absolute maximum receiver range used to
    # filter bad position reports, and to determine when local position
    # decoding is safe to use. Specify this in nautical miles (NM).
    MAX_RANGE="300"
    
    #
    # Networking options
    #
    
    # Port to listen on for HTTP connections. 0 disables.
    # HTTP defaults to being disabled unless you specify something here. I 
    # that you do not enable this, and instead serve the contents of
    # /usr/share/dump1090-mutability and JSON_DIR (below) using a proper
    # webserver. See /etc/lighttpd/conf-available/90-dump1090.conf
    # for an example configuration ("sudo lighty-enable-mod dump1090" to enable)
    HTTP_PORT="0"
    
    # Port to listen on for raw (AVR-format) input connections. 0 disables.
    RAW_INPUT_PORT="30001"
    
    # Port to listen on for raw (AVR-format) output connections. 0 disables.
    RAW_OUTPUT_PORT="30002"
    
    # Port to listen on for SBS-format output connections. 0 disables.
    SBS_OUTPUT_PORT="30003"
    
    # Port to listen on for Beast-format input connections. 0 disables.
    BEAST_INPUT_PORT="30004"
    
    # Port to listen on for Beast-format output connections. 0 disables.
    BEAST_OUTPUT_PORT="30005"
    
    # Port to listen on for FATSV-format output connections. 0 disables.
    FATSV_OUTPUT_PORT="10001"
    
    # TCP heartbeat interval in seconds. 0 disables.
    NET_HEARTBEAT="60"
    
    # Minimum output buffer size per write, in bytes.
    NET_OUTPUT_SIZE="500"
    
    # Maximum buffering time before writing, in seconds.
    NET_OUTPUT_INTERVAL="1"
    
    # TCP buffer size, in bytes
    NET_BUFFER="262144"
    
    # Bind ports on a particular address. If unset, binds to all interfaces.
    # This defaults to binding to localhost. If you need to allow remote
    # connections, change this.
    NET_BIND_ADDRESS=""
    
    #
    # Misc options
    #
    
    # Interval (in seconds) between logging stats to the logfile. 0 disables.
    STATS_INTERVAL="3600"
    
    # Path to write json state to (for use with an external webserver). Blank disables.
    JSON_DIR="/run/dump1090-mutability"
    
    # Interval between writing json state (in seconds). 0 disables.
    JSON_INTERVAL="1"
    
    # Accuracy of receiver location to write to json state, one of "exact" / "approximate" / "none"
    JSON_LOCATION_ACCURACY="approximate"
    
    # Set to yes to log all decoded messages
    # This can get large fast!
    LOG_DECODED_MESSAGES="no"
    
    # Additional options that are passed to the Daemon.
    EXTRA_ARGS="--mlat --net --net-http-port 8080"
    And the nc scripts:

    Code:
    #!/bin/sh
    sleep 20
    while :
    do
      nc -d localhost 31006 | nc -q1 localhost 30004
      sleep 15
    done
    Code:
    #!/bin/sh
    sleep 10
    while :
    do
      nc -d localhost 31007 | nc -q1 localhost 30004
    sleep 15  
    done
    T-VHHH55 http://bobsaget.mooo.com:8080
    Last edited by jb_bak; 2015-08-31 at 01:52.

  6. #336
    First officer
    Join Date
    Mar 2013
    Location
    Arhus (T-EKAH3), Denmark
    Posts
    345
    I have been following one aircraft I know not to be ADS-B equipped flying along the north coast of The Nederlands, and clearly some of the Raspberry Pi feeders are feeding Flight Aware calculated positions back into FR24.

    So fare I have seen T-EHAM63 and T-EHSB7 shown as the radar for this aircraft (OY-EUR). Something should be done to weed these position reports out.

  7. #337
    Passenger
    Join Date
    Sep 2015
    Posts
    1
    Hello, I am feeding with a Raspbery PI 2 + MLAB feature.

    Reading this post it seems to be a problem the fact that Raspberry PI does not have a hardware clock, as far as I understand having NTP is not enough.

    Would things be better if we buy a hardware clock, like the mini rtc clock ?

    If this could improve things, I would be ready to buy it.

  8. #338
    Passenger
    Join Date
    Aug 2015
    Location
    Guernsey (T-EGJB6)
    Posts
    11
    Using an RTC clock would be unlikely to improve things as far as I'm aware.

    The main issue is the relative offset from true UTC for each of the units which is why internet NTP doesn't improve things - it's very dependent on network delay and jitter (variation in delay). FR24 gets around this by calculating the relative offset for PI feeders by comparing the timestamps and arrival times for a known Mode-S packet containing a definite position. It effectively performs the MLAT calculation on that packet, then reverse-engineers the relative offsets of the PI stations to get the best match between that and the real position. Any other packets received at a similar time (in the order of seconds) can be reasonably safely assumed to have the same offset before the clock drifts, so the system is self-adjusting. In theory the clocks could be out by hours or days and still work.

    I personally use a PPS-enabled GPS module to feed NTP on my PI. This won't stop FR24 calculating the offset from my data feed, but at least I know it will (or should) be consistently reasonably close to zero so may help improve accuracy.

    See http://www.ebay.co.uk/itm/New-Ublox-...-/161648903960 for a similar module to mine. The PPS output isn't presented on the pin-header on this unit, but you can easily solder a wire to it.

    There's some good information on the following links on how to configure things:

    http://ntpi.openchaos.org/pps_pi/
    http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html

    The only trouble is that the module needs to be outside to get a signal and the PI relatively close. Mine is currently out in a weather-proof box together with the RTL dongle which works well. However, this week's project is to change over to an external GPS antenna and move the PI back indoors, since my 5V PSU for the PI sprays interference right across my VHF reception on airband, marine and NOAA / Meteor Sats as the antennas are nearby on the roof

    HTH
    Last edited by cbgsy; 2015-09-05 at 16:28.

  9. #339
    First officer
    Join Date
    Mar 2013
    Location
    Arhus (T-EKAH3), Denmark
    Posts
    345
    Getting confused about the status I get from the feeder...

    How does the lines
    "FR24 Tracked AC: nn"
    and
    "FR24 MLAT AC seen: mm"
    relate to oneanother?

    Sometimes the numbers are the same, and sometimes they are different but always similar.
    RPI Status.JPG

    Initially i thought 'tracked' referred to ADS-B aircraft and 'MLAT seen' to MLAT contribution, but the numbers seems related in some way.

  10. #340
    Passenger
    Join Date
    Aug 2015
    Location
    Guernsey (T-EGJB6)
    Posts
    11
    Looking forward to the Guernsey Air Display, this Thursday, 10th Sept.

    My PI MLAT feeder has clear coverage right in front of the display zone, so will be a good test for other low-altitude coverage in the area to see if we can pick anything up on FR24.

    See http://www.guernseyairdisplay.com/#!programme/ckqh for details (all times UK / BST)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •