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

  • falcongsr
    replied
    These non-ADS-B MLAT tracks are causing issues in the San Francisco Bay Area - I'm seeing the same thing, but unfortunately we have two different T-SJCNN receivers posting two different aircraft coordinates with different ICAO numbers for the same aircraft! So flightradar24 is showing TWO airplanes where there are none actually transmitting ADS-B coordinates.

    I'm all for more aircraft but these need to be handled properly (throwing away the aircraft with the invalid ICAO and categorizing the valid track as MLAT would be nice). Seeing two aircraft near each other with nearly the same altitude is a bit surprising but I've gotten used to filtering it mentally. The inaccuracy of the MLAT receivers is a little jarring as well when you're used to observing solid ADS-B coordinates too but that is another topic.

    Leave a comment:


  • numbat
    replied
    Feed no longer working

    My feed appears to no longer be working. The last accepted AC was:

    Code:
    2015-10-17 03:49:31 | [mlat][i]Pinging the server
    2015-10-17 03:49:31 | [mlat][i]Stats 564633/14
    2015-10-17 03:49:35 | [feed][i]sent 1 AC in 1 packet
    2015-10-17 03:49:52 | [mlat][i]Pinging the server
    2015-10-17 03:49:52 | [mlat][i]Stats 564633/0
    Here's the startup sequence:

    Code:
    2015-10-17 19:02:30 | [main][i]FR24 Feeder/Decoder [0x02117000]
    2015-10-17 19:02:30 | [main][i]Version: 1.0.14-11/generic
    2015-10-17 19:02:30 | [main][i]Built on 20150828-0958 (r:master-8c35732.git/Linux/armv7l)
    2015-10-17 19:02:30 | [main][i]Automatic updates are ENABLED
    2015-10-17 19:02:30 | [main][i]Copyright 2008-2015 (c) Piotr Pawluczuk
    2015-10-17 19:02:30 | [main][i]Flightradar24 AB(http : //flightradar24.com)
    2015-10-17 19:02:30 | [main][i]DNS mode: LIBC
    2015-10-17 19:02:30 | ERROR
    2015-10-17 19:02:30 | [w]Detected --net argument for dump1090, disabling internal BS feed!
    2015-10-17 19:02:30 | [main][i]Reader 0 started
    2015-10-17 19:02:30 | [main][i]MLAT data feed started
    2015-10-17 19:02:30 | [mlat][i]Waiting for MLAT configuration
    2015-10-17 19:02:30 | [reader][i][0]Initializing reader
    2015-10-17 19:02:30 | [reader][i][0]Connecting to Generic receiver via (exe : ///usr/lib/fr24/dump1090 --net --raw --mlat)
    2015-10-17 19:02:30 | [reader][i][0]Connected to the receiver, authenticating
    2015-10-17 19:02:30 | [master][i]Starting processing thread
    2015-10-17 19:02:30 | [httpd][i]Server started, listening on 0.0.0.0:8754
    2015-10-17 19:02:30 | [reader][i][0]Authenticated, processing messages
    2015-10-17 19:02:31 | [time][i]Synchronizing time via NTP
    2015-10-17 19:02:35 | [time][i]Time synchronized correctly, offset +0.0023 seconds
    2015-10-17 19:02:35 | [main][i]Feed Network client started
    2015-10-17 19:02:35 | [feed][i]Downloading configuration
    2015-10-17 19:02:35 | [feed][c]Interval: 5s
    2015-10-17 19:02:35 | [feed][c]Latitude: [deleted]
    2015-10-17 19:02:35 | [feed][c]Longitude: [deleted]
    2015-10-17 19:02:35 | [feed][c]GND: YES
    2015-10-17 19:02:35 | [feed][c]NonADSB: YES
    2015-10-17 19:02:35 | [feed][c]Timestamps: optional
    2015-10-17 19:02:35 | [feed][c]Max range AIR: 350.0nm
    2015-10-17 19:02:35 | [feed][c]Max range GND: 100.0nm
    2015-10-17 19:02:35 | [feed][i]defined 1 server
    2015-10-17 19:02:35 | [feed][n]KIZA1@83.140.21.66:8099/UDP
    2015-10-17 19:02:35 | [feed][n]connecting
    2015-10-17 19:02:35 | [stats][i]Stats thread started
    2015-10-17 19:02:36 | [mlat][i]MLAT configuration received, service ENABLED
    2015-10-17 19:02:36 | [mlat][i]Starting MLAT with preconfigured position: [deleted]
    2015-10-17 19:02:36 | [mlat][i]MLAT bandwidth reduction active, level 1
    2015-10-17 19:02:36 | [mlat][i]Configuring UDP connection udp : //usa-2.fr24.com:19788
    2015-10-17 19:02:36 | [mlat][i]Registering MLAT station
    2015-10-17 19:02:56 | [mlat][i]Registering MLAT station: FAILURE
    2015-10-17 19:02:57 | [feed][n]connected via TCP
    2015-10-17 19:02:57 | [feed][n]switching to UDP
    2015-10-17 19:02:57 | [feed][n]working
    2015-10-17 19:02:57 | [mlat][i]Configuring UDP connection udp : //usa-2.fr24.com:19788
    2015-10-17 19:02:57 | [mlat][i]Registering MLAT station
    2015-10-17 19:02:58 | [mlat][i]Registering MLAT station: SUCCESS
    2015-10-17 19:03:00 | [mlat][i]Pinging the server
    Then after a few minutes:

    Code:
    2015-10-17 19:12:20 | [mlat][i]Stats 564633/0
    2015-10-17 19:12:32 | [feed][n]ping 19
    2015-10-17 19:12:35 | [time][i]Synchronizing time via NTP
    2015-10-17 19:12:36 | [stats][e]Cached feed_id=15792 for network T
    2015-10-17 19:12:36 | [stats][i]sent 16 bytes
    2015-10-17 19:12:39 | [time][i]Time synchronized correctly, offset +0.0016 seconds
    2015-10-17 19:12:46 | [reader][w][0]Global timeout exceeded, 0 msgs, 0 resyncs, reconnecting
    2015-10-17 19:12:46 | [reader][i][0]Connection terminated
    2015-10-17 19:12:46 | [main][i]Terminating child process 17482 with SIGETERM
    2015-10-17 19:12:50 | [mlat][i]Pinging the server
    2015-10-17 19:12:50 | [mlat][i]Stats 564633/0
    2015-10-17 19:12:51 | [reader][i][0]Connecting to Generic receiver via (exe:///usr/lib/fr24/dump1090 --net --raw --mlat)
    2015-10-17 19:12:51 | [reader][i][0]Connected to the receiver, authenticating
    2015-10-17 19:12:51 | [reader][i][0]Authenticated, processing messages
    2015-10-17 19:13:02 | [feed][n]ping 20
    2015-10-17 19:13:19 | [mlat][i]Pinging the server
    Thanks for any help,

    numbat
    T-KIZA1

    p.s. I had to break up things that look like links to get past the forum link filter.

    Leave a comment:


  • numbat
    replied
    I think T-KBUR1 might be doing the same thing. I watched a non-ADS-B Southwest 737 (A8A860, LAX->OAK) go overhead on port 30003, and T-KIZA2 picked it up, then on the other side of the Grapevine it kicked over to T-KBUR1, then T-KMHV1 in Kern County, then T-MLAT2 west of Bakersfield, then T-KOAR1, and now finally back to T-MLAT2 just south of Kettleman City.

    Looks like this is a very common problem. At least FR24 can handle an aircraft apparently going from ADS-B to non-ADS-B, then apparently back to ADS-B in one flight! :-)

    Stacey
    T-KIZA1

    Leave a comment:


  • rodeo
    replied
    Originally posted by numbat View Post
    Ah! Finally an explanation for T-KIZA2, which for over a month now has been showing up on FR24 as the radar for almost all northern Los Angeles County MLAT aircraft. Basically almost all MLAT aircraft suddenly disappeared from my area, and now I know why.
    We have the same issue here in Sydney - T-YSSY51 is feeding "synthetic" (FA generated) MLAT data to FR... and is probably oblivious to the fact.

    I really wish FlightRadar admin would get off their butts and contact the operators of the T feeders doing this and get them to sort it out. It's not as though they won't know about them - the rest of us whinge about it on here enough

    Leave a comment:


  • KK6LDW
    replied
    Indeed. I feel your pain, neighbor.

    J.R.
    T-KIZA3

    Leave a comment:

Working...
X