Archived - Beta test MLAT software for Raspberry Pi

[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

[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]

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-

[Kemistry]

Do we have to prepare for leap-second event on 1 Jan 2017? Just reboot after midnight and all will be fixed?

[Dundee]

Do we have to prepare for leap-second event on 1 Jan 2017? Just reboot after midnight and all will be fixed?

FR24feed software will synchronize time via NTP server every 10 minutes automatically...
I think no need to worry about it...

[Skorpion]

Hi, i'm T-LIBP17. In the monitor.txt page i've this log:

mlat-mode="UDP"
mlat-number-seen="8"
mlat-ok="YES"
mlat-started="YES"
mlat-time-last-ping="1485083155"
mlat-time-last-push="1485083161"
mlat-time-last-push_count="18"
mlat-time-last-seen="1485083162"
mlat-time-stats="1485083166"
mlat-uplink-stats="0"
mlat_problem="no-config"

what's mean mlat_problem="no-config"?

[elljay]

Hi, no idea, but mine says the same but is happily uploading mlat data! frfeed24.log says:

2017-01-22 11:56:56 | [mlat][i]Pinging the server
2017-01-22 11:56:56 | [mlat][i]Stats 86527432/1398

[Skorpion]

So my Mlat is running correctly? Why i'm still T-LIBP and not F-LIBP?

[elljay]

Looks ok yes.

T- are for people running the client on RPi, Linux etc

F- are for people with one of the FR24 boxes (https://www.flightradar24.com/apply-for-receiver)

[Skorpion]

Looks ok yes.

T- are for people running the client on RPi, Linux etc

F- are for people with one of the FR24 boxes

received. thanks a lot!

[takshing2001]

excuse me May i ask how to see RPI3 Running status

in the past i use windows fr24feed in the program i can see

[i]sent * planes in 1 packets
...

RPI3 how Show to running status by ssh ?

[Oblivian]

excuse me May i ask how to see RPI3 Running status

in the past i use windows fr24feed in the program i can see




RPI3 how Show to running status by ssh ?

It's been explained a few times in this thread.
But also laid out in some help guides.. You cannot get the same information all the time so the web page and your account stats should be used to check status

https://forum.flightradar24.com/threads/9866-Fr24feed-software-Additional-FAQs-and-Info

[JoeinAK]

Hello,
I was hopping to get some help with the installation, I get this error when I run the automated script. However I just tried posting the error message but it's not letting me beacuse it has links in it, so I'm attaching an image of the error. please help as I'd love to contribute.

Screen Shot 2017-04-15 at 9.53.15 PM.png

Thanks
Joe

[mrcarlos]

are you on Linux or Windows? do you have any proxy or are vpn?

Sent from my SM-N910F using Tapatalk

[JoeinAK]

are you on Linux or Windows? do you have any proxy or are vpn?

Sent from my SM-N910F using Tapatalk

I am running on Raspberry Pi, Raspbian, Linux. No VPNs or Proxys. It seems to be repo issue on fr24 side but I'm not sure. Was hopping somebody can recognize the errors.