Archived - Beta test MLAT software for Raspberry Pi

[Wolli]

2nd Update concerning: [mlat][e]Received MLAT timestamp error: 0 seconds!

After several days of MLAT "working as it should" (seen with my eyes) the - by me myself - stated "error" ...
-> [mlat][e]Received MLAT timestamp error: 0 seconds!
is again back here.

Though I explicitely appreciate this posting of @WolfInTheAir (many thanks!), my wish is to see an "official FR24 posting" concerning FR24's handling of volunteer MLAT feeders' (like e.g. me) problems.

Motivation for my request:
We - the volunteers - are investing time and money to help/assist FR24 being able to spread good/best quality flight data to "the world". We like to do so. However, when problems (seen with our eyes) arise, we would like to have some info, why.

* Maybe, the data quality of an individual feeder is not so good, as FR24 requires. A suggestion by FR24, what the feeder (person) could do to enhance data quality, would be warmly welcome.

* Maybe, participation in MLAT feeding generally requires the individual feeder to supply data of many dozens of ACs at the same time to ensure "good quality MLAT data". Maybe, MLAT-feeders seeing just a few dozens of ACs have a "natural" MLAT data quality problem.

I understand, that FR24 probably won't put all its cards "open on the table", due to business secrets. That's ok.

However, my current feeling is, that we currently do not receive sufficient information concerning MLAT problems/issues.

Consequently, it would be nice to see/read some more official FR24 info about MLAT issues.

So I politely invite FR24 to supply us with some more info concerning MLAT problems. This would be very rewarding. May we have hope? Kind regards, -Wolli-

[Wolli]

Update concerning: [mlat][e]Received MLAT timestamp error: 0 seconds!

Hi all,

after several days "living" with that error (I checked that every 2 days or so), today I noticed that the reported
-> [mlat][e]Received MLAT timestamp error: 0 seconds!
is no more appearing in my feeder's log. I don't know, why.

I assume the FR24 guys are - from time to time - changing the behaviour of their MLAT-servers, in a continuously ongoing process of enhancing MLAT quality. However, this is just speculation.

Greetings, -Wolli-

[Wolli]

[mlat][e]Received MLAT timestamp error: 0 seconds!

Hi all,

after bringing my RPi3 to live I am feeding with MLAT enabled for some weeks now.

Initial problems caused by the MLAT server mlat-1.fr24.com have been solved two weeks ago (obviously wrong MLAT server configuration, see from posting #8 on http://forum.flightradar24.com/threa...ing-Pi24-error).

Now since 2 days, a new problem occured. I see the line
-> [mlat][e]Received MLAT timestamp error: 0 seconds!
in the log, and obviously no more MLAT data is transferred (always line [mlat][i]Stats 6807269/0 in the log), although "sudo service fr24feed diagnostics" states
-> (example): "[ ok ] FR24 MLAT: ok [UDP]."

Here an example log of a feed session (started without "service" for "bug mining"):
pi@raspberrypi:~ $ sudo fr24feed start
2016-11-22 18:22:11 | [main][i]FR24 Feeder/Decoder
2016-11-22 18:22:11 | [main][i]Version: 1.0.18-7/generic
2016-11-22 18:22:11 | [main][i]Built on Jul 11 2016 09:24:44 (HEAD-91e2757.git/Linux/armv7l)
2016-11-22 18:22:11 | [main][i]Copyright 2012-2016 Flightradar24 AB
2016-11-22 18:22:11 | [main][i]http://flightradar24.com
2016-11-22 18:22:12 | [main][i]DNS mode: LIBC
2016-11-22 18:22:12 | [main][i]Automatic updates are DISABLED
2016-11-22 18:22:12 | ERROR
2016-11-22 18:22:12 | [httpd][i]Server started, listening on 0.0.0.0:8754
2016-11-22 18:22:12 | [main][i]Reader thread started
2016-11-22 18:22:12 | [main][i]MLAT data feed started
2016-11-22 18:22:12 | [master][i]Starting processing thread
2016-11-22 18:22:12 | [reader][i]Initializing reader
2016-11-22 18:22:12 | [reader][i]Connecting to DVBT receiver via (exe:///usr/lib/fr24/dump1090 --net --fix --raw --mlat)
2016-11-22 18:22:12 | [reader][i]Connected to the receiver, configuring
2016-11-22 18:22:12 | [reader][i]Configured, processing messages
2016-11-22 18:22:12 | [mlat][i]Waiting for MLAT configuration
Found 1 device(s):
0: Generic, RTL2832U, SN: 77771111153705700 (currently selected)
Found Rafael Micro R820T tuner
Max available gain is: 49.60
Setting gain to: 49.60
Exact sample rate is: 2000000.052982 Hz
Gain reported by device: 49.60
2016-11-22 18:22:12 | [reader][w]Setting new UTC offset: 0!
2016-11-22 18:22:13 | [time][i]Synchronizing time via NTP
2016-11-22 18:22:17 | [time][i]Time synchronized correctly, offset +0.0003 seconds
2016-11-22 18:22:17 | [main][i]Feed Network client started
2016-11-22 18:22:17 | [feed][i]Downloading configuration
2016-11-22 18:22:17 | [feed][c]Interval: 5s
2016-11-22 18:22:17 | [feed][c]Latitude: 51.xxxxxxxx
2016-11-22 18:22:17 | [feed][c]Longitude: 6.xxxxxx
2016-11-22 18:22:17 | [feed][c]GND: YES
2016-11-22 18:22:17 | [feed][c]NonADSB: YES
2016-11-22 18:22:17 | [feed][c]Timestamps: optional
2016-11-22 18:22:17 | [feed][c]Max range AIR: 350.0nm
2016-11-22 18:22:17 | [feed][c]Max range GND: 100.0nm
2016-11-22 18:22:17 | [stats][i]Stats thread started
2016-11-22 18:22:17 | [feed][i]defined 5 servers
2016-11-22 18:22:17 | [feed][n]EDDL27@83.140.21.68:8099/UDP
2016-11-22 18:22:17 | [feed][n]connecting
2016-11-22 18:22:17 | [feed][n]connected via UDP (fd 8)
2016-11-22 18:22:17 | [feed][n]working
2016-11-22 18:22:17 | [feed][i]sent 1,0 AC
2016-11-22 18:22:18 | [mlat][i]MLAT configuration received, service ENABLED
2016-11-22 18:22:18 | [mlat][i]Starting MLAT with preconfigured position: 51.xx,6.xx,187.0
2016-11-22 18:22:18 | [mlat][i]MLAT bandwidth reduction active, level 1
2016-11-22 18:22:18 | [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
2016-11-22 18:22:18 | [mlat][i]Registering MLAT station
2016-11-22 18:22:18 | [mlat][i]Registering MLAT station: SUCCESS
2016-11-22 18:22:22 | [feed][i]sent 9,0 AC
2016-11-22 18:22:23 | [mlat][i]Received ADS-B time references AC:
2016-11-22 18:22:23 | [mlat][i] 343202
2016-11-22 18:22:23 | [mlat][i] 400DB1
2016-11-22 18:22:23 | [mlat][i] 4D00D8
2016-11-22 18:22:23 | [mlat][i] A76DF1
2016-11-22 18:22:27 | [feed][i]sent 8,0 AC
2016-11-22 18:22:32 | [mlat][e]Received MLAT timestamp error: 0 seconds!
2016-11-22 18:22:32 | [mlat][i]Pinging the server
2016-11-22 18:22:32 | [mlat][i]Stats 6807269/6807269
2016-11-22 18:22:32 | [feed][i]sent 10,0 AC
2016-11-22 18:22:38 | [feed][i]sent 11,0 AC
2016-11-22 18:22:48 | [feed][i]sent 9,0 AC
2016-11-22 18:22:53 | [mlat][i]Pinging the server
2016-11-22 18:22:53 | [mlat][i]Stats 6807269/0
2016-11-22 18:22:53 | [feed][i]sent 9,0 AC
2016-11-22 18:22:58 | [feed][i]sent 9,0 AC
2016-11-22 18:23:03 | [feed][i]sent 7,0 AC
2016-11-22 18:23:08 | [feed][i]sent 10,0 AC
2016-11-22 18:23:13 | [mlat][i]Pinging the server
2016-11-22 18:23:13 | [mlat][i]Stats 6807269/0
2016-11-22 18:23:14 | [feed][i]sent 10,0 AC
2016-11-22 18:23:19 | [feed][i]sent 11,0 AC
2016-11-22 18:23:20 | [feed][i]filtering out 13 overlapping AC (saving bandwidth)
2016-11-22 18:23:24 | [feed][i]sent 0,9 AC
2016-11-22 18:23:25 | [feed][i]removed 1 of 19 AC
2016-11-22 18:23:29 | [feed][i]sent 0,8 AC
2016-11-22 18:23:33 | [mlat][i]Received ADS-B time references AC:
2016-11-22 18:23:33 | [mlat][i] 343202
2016-11-22 18:23:33 | [mlat][i] 400DB1
2016-11-22 18:23:33 | [mlat][i] 4BAAD0
2016-11-22 18:23:33 | [mlat][i] 4CA223
2016-11-22 18:23:33 | [mlat][i] 4D00D8
2016-11-22 18:23:33 | [mlat][i]Pinging the server
2016-11-22 18:23:33 | [mlat][i]Stats 6807269/0
2016-11-22 18:23:34 | [feed][i]sent 4,8 AC
2016-11-22 18:23:37 | [feed][i]removed 2 of 20 AC
2016-11-22 18:23:39 | [feed][i]sent 0,9 AC
2016-11-22 18:23:44 | [feed][i]sent 0,9 AC
2016-11-22 18:23:49 | [feed][i]sent 0,8 AC
2016-11-22 18:23:49 | [feed][n]syncing stream async: 1
2016-11-22 18:23:50 | [feed][n]syncing stream result: 1
2016-11-22 18:23:53 | [mlat][i]Pinging the server
2016-11-22 18:23:53 | [mlat][i]Stats 6807269/0
2016-11-22 18:23:54 | [feed][i]sent 0,9 AC
2016-11-22 18:23:59 | [feed][i]sent 0,7 AC
2016-11-22 18:24:04 | [feed][i]sent 0,7 AC
2016-11-22 18:24:09 | [feed][i]sent 0,8 AC
2016-11-22 18:24:13 | [mlat][i]Pinging the server
2016-11-22 18:24:13 | [mlat][i]Stats 6807269/0
2016-11-22 18:24:15 | [feed][i]sent 2,9 AC
2016-11-22 18:24:17 | [feed][i]removed 2 of 19 AC
2016-11-22 18:24:20 | [feed][i]sent 4,9 AC
2016-11-22 18:24:21 | [feed][i]filtering out 11 overlapping AC (saving bandwidth)
2016-11-22 18:24:25 | [feed][i]sent 7,7 AC
2016-11-22 18:24:30 | [feed][i]sent 5,6 AC
^C2016-11-22 18:24:31 | [main][i]Terminating on user request
2016-11-22 18:24:31 | [main][i]Terminating worker threads
2016-11-22 18:24:31 | [reader][i]Connection terminated
2016-11-22 18:24:31 | [main][i]Terminating child process 10813 with SIGETERM
2016-11-22 18:24:31 | [reader][i]Terminating on request
2016-11-22 18:24:35 | [master][i]Terminating on request
2016-11-22 18:24:35 | [feed][n]busy
2016-11-22 18:24:35 | [feed][n]disconnected
2016-11-22 18:24:35 | [feed][x]Feeding thread terminated
pi@raspberrypi:~ $

Note especially the log lines
-> 2016-11-22 18:22:32 | [mlat][e]Received MLAT timestamp error: 0 seconds!
and the "zero" MLAT data
-> [mlat][i]Stats 6807269/0

Questions:
1) Any ideas?
2) Do you also observe "[mlat][e]Received MLAT timestamp error: 0 seconds!" in your logs?

Greetings from Germany, Wolli

[valentajn]

Thank you all for your help, now works as it should.

[abcd567]

If you have flight aware or any other feeders working do NOT configure fr25 for dvbt. You need avrtcp

To change settings, type <IP of PI>:8754/settings.html in your browser address bar.
Set Receiver AVR(TCP), Host 127.0.0.1:30002
Click Save button and then Restart button at bottom right corner of settings page.
FR24 settings.png


To see status, type <IP of PI>:8754 in your browser address bar.
FR24 status.png

[Oblivian]

Help, please! My FR24Feed v. 1.0.18-7 on RaspberryPI doesn't work properly. I do not know where to start, but it is not transmitting data to the flightradar24.com, but in FlightAware dump1090 I see the flights. Tell me what to do. Write me what more data I have provide for full understanding of my problem. Sorry for my english.
"ac_map_size="3072"
build_arch="armv7l"
build_flavour="generic"
build_os="Linux"
build_revision="HEAD-91e2757.git"
build_timetamp="Jul 11 2016 09:24:44"
build_version="1.0.18-7"
cfg_baudrate=""
cfg_bs="yes"
cfg_host="192.168.1.88:30002"
cfg_mpx="yes"
cfg_path=""
cfg_raw="yes"
cfg_receiver="dvbt"
cfg_windowmode="0"
d11_map_size="0"
feed_alias="T-UKDD8"
feed_configured_mode="UDP"
feed_current_mode="UDP"
feed_current_server="83.140.21.112"
feed_last_attempt_time="1478033487"
feed_last_config_attempt="1478033487"
feed_last_config_info=""
feed_last_config_result="success"
feed_last_connected_time="1478033487"
feed_status="connected"
feed_status_message=""
fr24key="3b***************"
last_json_utc="1478034928"
last_rx_connect_status="OK"
last_rx_connect_time="1478034999"
last_rx_connect_time_s="2016-11-01 21:16:39"
mlat-ok="NO"
mlat-started="YES"
mlat_problem="no-config"
msg_ring_full="0"
msg_ring_length="0"
offline-mode="no"
rx_connected="0"
shutdown="no"
time_update_utc="1478034945"
time_update_utc_s="2016-11-01 21:15:45"
timing_is_valid="1"
timing_last_drift="+0.0012"
timing_last_offset="+0.0003"
timing_last_result="success"
timing_source="NTP"
timing_time_last_attempt="1478034697"
timing_time_last_success="1478034697"
timing_time_since_last_success="606"

$ sudo service fr24feed diagnostics
[ ok ] FR24 Feeder/Decoder Process: running.
[ ok ] FR24 Stats Timestamp: 2016-11-01 21:39:55.
[ ok ] FR24 Link: connected [UDP].
[ ok ] FR24 Radar: T-UKDD8.
[ ok ] FR24 Tracked AC:.
[FAIL] Receiver: down ... failed!
[FAIL] FR24 MLAT: not running ... failed!

If you have flight aware or any other feeders working do NOT configure fr25 for dvbt. You need avrtcp

Sent from my XT1092 using Tapatalk

[valentajn]

Help, please! My FR24Feed v. 1.0.18-7 on RaspberryPI doesn't work properly. I do not know where to start, but it is not transmitting data to the flightradar24.com, but in FlightAware dump1090 I see the flights. Tell me what to do. Write me what more data I have provide for full understanding of my problem. Sorry for my english.
"ac_map_size="3072"
build_arch="armv7l"
build_flavour="generic"
build_os="Linux"
build_revision="HEAD-91e2757.git"
build_timetamp="Jul 11 2016 09:24:44"
build_version="1.0.18-7"
cfg_baudrate=""
cfg_bs="yes"
cfg_host="192.168.1.88:30002"
cfg_mpx="yes"
cfg_path=""
cfg_raw="yes"
cfg_receiver="dvbt"
cfg_windowmode="0"
d11_map_size="0"
feed_alias="T-UKDD8"
feed_configured_mode="UDP"
feed_current_mode="UDP"
feed_current_server="83.140.21.112"
feed_last_attempt_time="1478033487"
feed_last_config_attempt="1478033487"
feed_last_config_info=""
feed_last_config_result="success"
feed_last_connected_time="1478033487"
feed_status="connected"
feed_status_message=""
fr24key="3b***************"
last_json_utc="1478034928"
last_rx_connect_status="OK"
last_rx_connect_time="1478034999"
last_rx_connect_time_s="2016-11-01 21:16:39"
mlat-ok="NO"
mlat-started="YES"
mlat_problem="no-config"
msg_ring_full="0"
msg_ring_length="0"
offline-mode="no"
rx_connected="0"
shutdown="no"
time_update_utc="1478034945"
time_update_utc_s="2016-11-01 21:15:45"
timing_is_valid="1"
timing_last_drift="+0.0012"
timing_last_offset="+0.0003"
timing_last_result="success"
timing_source="NTP"
timing_time_last_attempt="1478034697"
timing_time_last_success="1478034697"
timing_time_since_last_success="606"

$ sudo service fr24feed diagnostics
[ ok ] FR24 Feeder/Decoder Process: running.
[ ok ] FR24 Stats Timestamp: 2016-11-01 21:39:55.
[ ok ] FR24 Link: connected [UDP].
[ ok ] FR24 Radar: T-UKDD8.
[ ok ] FR24 Tracked AC:.
[FAIL] Receiver: down ... failed!
[FAIL] FR24 MLAT: not running ... failed!

[maaw]

I have fr24feed running (1.0.18-7).

I have noticed that my log file /var/log/fr24feed.log is not being rotated (after months of being up). feed.flightradar24.com/fr24feed-manual.pdf seems to suggest that --logmode and --logpath need to be set to get this behavior. However the recent init scripts found in the debs (here feed.flightradar24.com) instead set arguments "--log-base=/var/log/fr24feed" and "--log-rotate=2".

I am running with the init script. With those parameters set I would expect log-rotate=2 to cause the logs to "rotate at midnight <and> keep for 72 hours".

Can anyone confirm that log rotation is working for them? In which case I'd guess it is a configuration issue on my side. If not is this a log rotation bug in fr24feed?

Thanks!

-- Ken

Make sure you have logrotate installed

sudo apt-get install logrotate

Plus in order to prevent SD/Flash memory wear due to repeated writing you should add

tmpfs /var/log tmpfs nodev,nosuid,size=50M 0 0

to your /etc/fstab

The above line will create a 50mb tmpfs partition (aka in RAM) mounted in /var/log that won't survive a reboot but won't wear your storage.

[Oblivian]

good question, i have the same problem. Every few minutes i've got the following logged from fr24.

2016-09-02 16:25:34 | [mlat][i]MLAT configuration received, service ENABLED
2016-09-02 16:25:34 | [mlat][i]Starting MLAT with preconfigured position: 49.xxx,x.52,xxx.x
2016-09-02 16:25:34 | [mlat][i]MLAT bandwidth reduction active, level 1
2016-09-02 16:25:34 | [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
2016-09-02 16:25:34 | [mlat][i]Registering MLAT station
2016-09-02 16:25:34 | [mlat][i]Registering MLAT station: SUCCESS
2016-09-02 16:25:37 | [feed][i]sent 47,0 AC
...
2016-09-02 16:25:47 | [feed][i]sent 48,0 AC
2016-09-02 16:25:50 | [mlat][i]No ADS-B time reference available (0/18)
2016-09-02 16:25:50 | [mlat][i]Pinging the server
2016-09-02 16:25:50 | [mlat][w]Could not ping MLAT server, result=-1000, number of errors=1
...
2016-09-02 16:26:22 | [mlat][i]No ADS-B time reference available (0/26)
2016-09-02 16:26:22 | [mlat][i]Pinging the server
2016-09-02 16:26:22 | [mlat][w]Could not ping MLAT server, result=-1000, number of errors=2
2016-09-02 16:26:22 | [mlat][i]Terminating connection
2016-09-02 16:26:22 | [feed][i]sent 0,50 AC
2016-09-02 16:26:23 | [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
2016-09-02 16:26:23 | [mlat][i]Registering MLAT station
2016-09-02 16:26:23 | [mlat][i]Registering MLAT station: SUCCESS

But the connection to dump1090 seems to work:

2016-09-21 18:37:48 | [feed][i]sent 20,33 AC
2016-09-21 18:37:49 | [feed][i]removed 2 of 88 AC
2016-09-21 18:37:49 | [feed][i]filtering out 57 overlapping AC (saving bandwidth)
2016-09-21 18:37:53 | [feed][i]removed 1 of 86 AC
2016-09-21 18:37:53 | [feed][i]sent 0,44 AC

i'm using fr24 on a RaspberryPi. I'm running PiAware with dump1090-mutability. Dump1090 is started with following options "--net --ppm 0 --fix --lat 49.12693 --lon 8.51934 --max-range 300 --net-ri-port 30001 --net-ro-port 30002 --net-bi-port 30004,30104 --net-bo-port 30005 --net-sbs-port 30003 --net-heartbeat 60 --net-ro-size 500 --net-ro-interval 1 --net-buffer 2 --stats-every 3600 --write-json /run/dump1090-mutability --write-json-every 1 --json-location-accuracy 1 --quiet --stats --stats-range --metric --forward-mlat --fix --aggressive".

My fr24feed.ini is set to:

receiver="avr-tcp"
fr24key="************"
host="127.0.0.1:30002"
bs="no"
raw="no"
logmode="1"
mlat="yes"
mlat-without-gps="yes"

But it seems mlat seems working:

root@flightradar:~# /etc/init.d/fr24feed diagnostics
[ ok ] FR24 Feeder/Decoder Process: running.
[ ok ] FR24 Stats Timestamp: 2016-09-21 16:50:29.
[ ok ] FR24 Link: connected [UDP].
[ ok ] FR24 Radar: T-******.
[ ok ] FR24 Tracked AC: 76.
[ ok ] Receiver: connected (195225624 MSGS/0 SYNC).
[ ok ] FR24 MLAT: ok [UDP].
[ ok ] FR24 MLAT AC seen: 71.

The dump1090-Webinterface showed up some "blue" planes - so it should work and PiAware seems to work with mlat (according to the FlightAware statistics page).

The question is: did mlat with fr24 work or not? Is it possible to use multiple clients for syncing the mlat information (PiAware and Flightradar24?)? :-/

Flightaware feeds MLAT back to the clients. This causes them to appear on Dump1090
FR24 does not. All positions are calculated server side. If they appear on the map as MLAT aircraft, and your MLAT status is OK you will be assisting this

What does set alarms off, is the 57 over-lapping being removed.

This indicates you are probably sending that MLAT data from flightaware back out to port 30002 again and duplicating them. Dump1090 needs to be configured on the right 'listen' port to prevent this

[Oblivian]

It wont be able to send data if there is none.. think you will find the "no mlat reference" may refer to lack of known position aircraft at the same time? Needs to have a known flying gps reference at same time to consider

Sent from my XT1092 using Tapatalk

[seb-lfga]

2016-09-26 18:43:40 | [mlat][i]Pinging the server
2016-09-26 18:43:41 | [mlat][w]Could not ping MLAT server, result=-1000, number of errors=2
2016-09-26 18:43:41 | [mlat][i]Terminating connection
2016-09-26 18:43:42 | [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788

I´ve checked over the last hour - mlat-1.fr24.com on Port 19788 is responding to Pings and connection attempts without any loss...

[seb-lfga]

Good day,

I took the chance today to re-setup my pi with jessie, dump1090-muta 1.15, FR24 and flightradar.

Dump1090 works fine, feed to flightradar works fine.

It seems FR24 is pushing to the servers, but I do get two strange errors I cannot explain:

No ADS-B time reference available (0/14)

and

2016-09-26 18:43:41 | [mlat][w]Could not ping MLAT server, result=-1000, number of errors=2
2016-09-26 18:43:41 | [mlat][i]Terminating connection
2016-09-26 18:43:42 | [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
2016-09-26 18:43:42 | [mlat][i]Registering MLAT station
2016-09-26 18:43:42 | [mlat][i]Registering MLAT station: SUCCESS

Thank you!


Seb



2016-09-26 18:43:03 | [feed][i]removed 1 of 45 AC
2016-09-26 18:43:05 | [feed][i]sent 0,18 AC
2016-09-26 18:43:07 | [feed][i]removed 1 of 44 AC
2016-09-26 18:43:08 | [mlat][i]No ADS-B time reference available (0/14)
2016-09-26 18:43:08 | [mlat][i]Pinging the server
2016-09-26 18:43:08 | [mlat][w]Could not ping MLAT server, result=-1000, number of errors=1
2016-09-26 18:43:10 | [feed][i]sent 0,17 AC
2016-09-26 18:43:11 | [feed][i]filtering out 14 overlapping AC (saving bandwidth)
2016-09-26 18:43:15 | [feed][i]sent 20,12 AC
2016-09-26 18:43:20 | [feed][i]sent 20,12 AC
2016-09-26 18:43:24 | [mlat][i]No ADS-B time reference available (0/15)
2016-09-26 18:43:25 | [feed][i]sent 20,12 AC
2016-09-26 18:43:27 | [feed][i]removed 1 of 44 AC
2016-09-26 18:43:30 | [feed][i]sent 20,12 AC
2016-09-26 18:43:35 | [feed][i]sent 20,12 AC
2016-09-26 18:43:40 | [feed][i]sent 20,13 AC
2016-09-26 18:43:40 | [mlat][i]No ADS-B time reference available (0/15)
2016-09-26 18:43:40 | [mlat][i]Pinging the server
2016-09-26 18:43:41 | [mlat][w]Could not ping MLAT server, result=-1000, number of errors=2
2016-09-26 18:43:41 | [mlat][i]Terminating connection
2016-09-26 18:43:42 | [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
2016-09-26 18:43:42 | [mlat][i]Registering MLAT station
2016-09-26 18:43:42 | [mlat][i]Registering MLAT station: SUCCESS
2016-09-26 18:43:45 | [feed][i]sent 23,13 AC
2016-09-26 18:43:50 | [feed][i]sent 20,13 AC
2016-09-26 18:43:55 | [feed][i]sent 20,13 AC

ac_map_size="3072"
build_arch="armv7l"
build_flavour="generic"
build_os="Linux"
build_revision="HEAD-91e2757.git"
build_timetamp="Jul 11 2016 09:24:44"
build_version="1.0.18-7"
cfg_baudrate=""
cfg_bs="no"
cfg_host="127.0.0.1:30002"
cfg_mpx="no"
cfg_path=""
cfg_raw="no"
cfg_receiver="avr-tcp"
cfg_windowmode="0"
d11_map_size="50"
feed_alias="T-LFGA10"
feed_configured_mode="UDP"
feed_current_mode="UDP"
feed_current_server="83.140.21.85"
feed_last_ac_sent_num="19"
feed_last_ac_sent_time="1474913343"
feed_last_attempt_time="1474907955"
feed_last_config_attempt="1474907955"
feed_last_config_info=""
feed_last_config_result="success"
feed_last_connected_time="1474907956"
feed_num_ac_tracked="40"
feed_status="connected"
feed_status_message=""
fr24key="blubb"
gps_tods="0"
last_json_utc="1474913279"
last_rx_connect_status="OK"
last_rx_connect_time="1474907941"
last_rx_connect_time_s="2016-09-26 16:39:01"
local_tods="65325"
mlat-mode="UDP"
mlat-number-seen="41"
mlat-ok="YES"
mlat-started="YES"
mlat-time-last-ping="1474913299"
mlat-time-last-seen="1474913332"
mlat-time-stats="1474913332"
mlat-uplink-stats="0"
mlat_problem="connection-broken"
msg_ring_full="0"
msg_ring_length="0"
num_messages="2102177"
num_resyncs="0"
offline-mode="no"
rx_connected="1"
shutdown="no"
time_update_utc="1474913326"
time_update_utc_s="2016-09-26 18:08:46"
timing_is_valid="1"
timing_last_drift="+0.0008"
timing_last_offset="+0.0005"
timing_last_result="success"
timing_source="NTP"
timing_time_last_attempt="1474912890"
timing_time_last_success="1474912890"
timing_time_since_last_success="607"

[_Jens_]

Hi, what does [mlat][i]No ADS-B time reference available (0/0) mean?
Thanks!

good question, i have the same problem. Every few minutes i've got the following logged from fr24.

2016-09-02 16:25:34 | [mlat][i]MLAT configuration received, service ENABLED
2016-09-02 16:25:34 | [mlat][i]Starting MLAT with preconfigured position: 49.xxx,x.52,xxx.x
2016-09-02 16:25:34 | [mlat][i]MLAT bandwidth reduction active, level 1
2016-09-02 16:25:34 | [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
2016-09-02 16:25:34 | [mlat][i]Registering MLAT station
2016-09-02 16:25:34 | [mlat][i]Registering MLAT station: SUCCESS
2016-09-02 16:25:37 | [feed][i]sent 47,0 AC
...
2016-09-02 16:25:47 | [feed][i]sent 48,0 AC
2016-09-02 16:25:50 | [mlat][i]No ADS-B time reference available (0/18)
2016-09-02 16:25:50 | [mlat][i]Pinging the server
2016-09-02 16:25:50 | [mlat][w]Could not ping MLAT server, result=-1000, number of errors=1
...
2016-09-02 16:26:22 | [mlat][i]No ADS-B time reference available (0/26)
2016-09-02 16:26:22 | [mlat][i]Pinging the server
2016-09-02 16:26:22 | [mlat][w]Could not ping MLAT server, result=-1000, number of errors=2
2016-09-02 16:26:22 | [mlat][i]Terminating connection
2016-09-02 16:26:22 | [feed][i]sent 0,50 AC
2016-09-02 16:26:23 | [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
2016-09-02 16:26:23 | [mlat][i]Registering MLAT station
2016-09-02 16:26:23 | [mlat][i]Registering MLAT station: SUCCESS

But the connection to dump1090 seems to work:

2016-09-21 18:37:48 | [feed][i]sent 20,33 AC
2016-09-21 18:37:49 | [feed][i]removed 2 of 88 AC
2016-09-21 18:37:49 | [feed][i]filtering out 57 overlapping AC (saving bandwidth)
2016-09-21 18:37:53 | [feed][i]removed 1 of 86 AC
2016-09-21 18:37:53 | [feed][i]sent 0,44 AC

i'm using fr24 on a RaspberryPi. I'm running PiAware with dump1090-mutability. Dump1090 is started with following options "--net --ppm 0 --fix --lat 49.12693 --lon 8.51934 --max-range 300 --net-ri-port 30001 --net-ro-port 30002 --net-bi-port 30004,30104 --net-bo-port 30005 --net-sbs-port 30003 --net-heartbeat 60 --net-ro-size 500 --net-ro-interval 1 --net-buffer 2 --stats-every 3600 --write-json /run/dump1090-mutability --write-json-every 1 --json-location-accuracy 1 --quiet --stats --stats-range --metric --forward-mlat --fix --aggressive".

My fr24feed.ini is set to:

receiver="avr-tcp"
fr24key="************"
host="127.0.0.1:30002"
bs="no"
raw="no"
logmode="1"
mlat="yes"
mlat-without-gps="yes"

But it seems mlat seems working:

root@flightradar:~# /etc/init.d/fr24feed diagnostics
[ ok ] FR24 Feeder/Decoder Process: running.
[ ok ] FR24 Stats Timestamp: 2016-09-21 16:50:29.
[ ok ] FR24 Link: connected [UDP].
[ ok ] FR24 Radar: T-******.
[ ok ] FR24 Tracked AC: 76.
[ ok ] Receiver: connected (195225624 MSGS/0 SYNC).
[ ok ] FR24 MLAT: ok [UDP].
[ ok ] FR24 MLAT AC seen: 71.

The dump1090-Webinterface showed up some "blue" planes - so it should work and PiAware seems to work with mlat (according to the FlightAware statistics page).

The question is: did mlat with fr24 work or not? Is it possible to use multiple clients for syncing the mlat information (PiAware and Flightradar24?)? :-/

[Graeme2812]

So my dump says 7/25

so 7 with positions and 25 total? So am i only reporting planes? What about the other 18?

Funny I was just thinking the same thing having had dump1090 running for a week or so now. I regularly get a mixture of aircraft with the green band and showing on the screen and some without. It tends to be the lower altitude ones that come without.

(See screenshot of Dump1090 map)
Untitled.jpg

My understanding is....and this is probably wrong!.....that the aircraft being received on Dump1090 without the green band/positions and Lat/Long reference are being received via Mode S and without ADS-B transmissions so therefore have no GPS/position coordinates available from this transmission alone, hence why they won't have their positions displayed. I'm assuming that the data from these aircraft without the positioning reports that I'm receiving are what is helping contribute towards FR24 MLAT calculations? (TDOA) etc. Assuming the remaining MLAT criteria is in place and were uploading data etc to the network?

I've always assumed the aircraft with the green banding (i.e with their positions known/displayed) are either having their Mode S transmissions received by a sufficient number of receivers to meet the minimum MLAT criteria, hence their position and Lat/Long is being displayed, or are being received via their ADS-B transmissions.

[bakerkj]

I don't have logging enabled, but it has always been hit and miss if it works correctly (it will also kill SD cards faster)

If unsure of the right args use the web interface to configure where it has dropdowns etc.

I tried configuration through the GUI. No changes to my configuration file.

-- Ken