Page 58 of 91 FirstFirst ... 848565758596068 ... LastLast
Results 571 to 580 of 901

Thread: Archived - Beta test MLAT software for Raspberry Pi

  1. #571
    Super Moderator
    Join Date
    May 2011
    Location
    T-NZCH1, PP:PH New Zealand
    Posts
    5,053
    Quote Originally Posted by MaCo View Post
    I am running dump1090 (mutability fork) on RTL dongle, with --net option activated. In fr24feed I configured receiver selection for option 4 - ModeS Beast and connection type Network connection. Finally I specified IP and port of data feed (default 30005 on dump1090) and disabled all data forwarding options to avoid conflicts with dump1090.

    In past, I had to run this configuration due to characteristics of my setup (ADS-B decoder and fr24feeder had to run on separate devices), currently it is mainly due to extended functionality of dump1090-mutability fork compared to FR24 fork.
    Odd. But good to know that combo works

    The norm would be use the AVR-TCP selection and out of dump1090 instead on 30002

    Not sure if dump1090 changes the beast output timestamps in a way that the MLAT upload portion will agree with.
    Posts not to be taken as official support representation - Just a helpful uploader who tinkers

  2. #572
    Passenger
    Join Date
    Jun 2015
    Posts
    4
    Quote Originally Posted by Oblivian View Post
    Odd. But good to know that combo works

    The norm would be use the AVR-TCP selection and out of dump1090 instead on 30002

    Not sure if dump1090 changes the beast output timestamps in a way that the MLAT upload portion will agree with.
    Good to know that AVR-TCP in fr24feed is the same format as RAW in dump1090. If I had known this, I would be using that configuration from the beginning

    One thing to mention - on mutability fork, default ports for RAW input and output are swapped compared to other forks (RAW output defaults to 30001).

    I'll continue with RAW feed then. Thanks again for your help.

  3. #573
    Super Moderator
    Join Date
    May 2011
    Location
    T-NZCH1, PP:PH New Zealand
    Posts
    5,053
    Has reminded me to add note re 30001. It's a pipe port. What goes in, goes out. Which could be dangerous (and possibly the reason for some feeders multiplexing feeds and sending position data from other sources)
    Posts not to be taken as official support representation - Just a helpful uploader who tinkers

  4. #574
    First officer
    Join Date
    Mar 2015
    Location
    T-KSJC28
    Posts
    335
    Any word on when FR24 will sort out pi MLAT for FR24? Is there still a timing issue holding it up?

  5. #575
    Team FR24 Olov's Avatar
    Join Date
    Feb 2010
    Location
    Stockholm, Sweden
    Posts
    197
    Quote Originally Posted by Sam26K View Post
    Any word on when FR24 will sort out pi MLAT for FR24? Is there still a timing issue holding it up?
    That is something that we work very hard on to bring back. I don't want to say when, but certainly as soon as possible!

    It's not a timing issue, more of a data volume issue.

  6. #576
    First officer
    Join Date
    Mar 2015
    Location
    T-KSJC28
    Posts
    335
    Quote Originally Posted by Olov View Post
    That is something that we work very hard on to bring back. I don't want to say when, but certainly as soon as possible!

    It's not a timing issue, more of a data volume issue.
    Looking forward to the return of FR24 MLAT and appreciate your teams efforts. Glad to hear it's not a timing issue.

    IMHO your major issue is trust in the source of the data. There should be a ranking based on "trust". It shouldn't be difficult to flag feeders that are leaking MLAT based data. If most of the feeders in a given area are not returning GPS data on an a/c and 1 feeder is feeding gps data for every a/c in the area, those feeders could be flagged to a much lower rank and less reliable source of data.

    Thanks again and looking forward to FR24 for pi returning soon! .

  7. #577
    First officer
    Join Date
    Mar 2015
    Location
    T-KSJC28
    Posts
    335
    BTW, not to beat a dead horse, but T-KSJC18 and T-KSJC12 are the worst MLAT leaks in the San Francisco bay area if not the world And they have no shame. My personal theory is that are intentionally "dithering" the feed to make it less accurate.
    Last edited by Sam26K; 2016-02-09 at 06:19.

  8. #578
    Passenger
    Join Date
    Apr 2015
    Posts
    2
    I have installed the new raspberry pi software version of 03.03.2016. The receiver is sbs1 via tcp network link.
    I think there is a problem. Previous version was working ok.
    Thanks in advance

    here is the output
    [ ok ] FR24 Feeder/Decoder Process: running.
    [ ok ] FR24 Stats Timestamp: 2016-03-03 19:52:47.
    [FAIL] FR24 Link: connecting ... failed!
    [ ok ] Receiver: connected (211631 MSGS/0 SYNC).
    [FAIL] FR24 MLAT: not running ... failed!

  9. #579
    Administrator piopawlu's Avatar
    Join Date
    Mar 2011
    Location
    Sweden
    Posts
    226
    Wait a while after you restart the service, it works just fine here, but you need to give it a minute to update status file.

  10. #580
    Passenger
    Join Date
    Aug 2015
    Location
    Germany
    Posts
    1
    My RPi auto-updated to 18.4 tonight, nothing else changed on my side.
    This version now uses TCP for ADS-B (8099) and continues using UDP for MLAT (19788).
    Prior versions used UDP for both, ADS-B and MLAT. Is this intended?

    The feeder-sw first tries UDP, the packet is definitely sent.
    No response from the FR24 side is received for 20 seconds
    and the feeder-sw switches to TCP. The SYN is ACKed immediately.

Posting Permissions

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