Archived - Beta test MLAT software for Raspberry Pi

[milair]

It seems to be another bug. F5 a few times and it will populate. Frustrating but appears to be on both Win32 and Pi versions now. I get it too

Yep, that's done the trick, thanks for that, I just need to sort the 8080 feed now

[Oblivian]

Yep, that's done the trick, thanks for that, I just need to sort the 8080 feed now

--net --net-http-port 8080

In the additional parameters field if you installed the FR package. If you have done D1090 on its own, it may need to be reconfigured or script options edited before restarting it/Pi
Don't forget to also turn off BS and RAW options.

[milair]

--net --net-http-port 8080

In the additional parameters field if you installed the FR package. If you have done D1090 on its own, it may need to be reconfigured or script options edited before restarting it/Pi
Don't forget to also turn off BS and RAW options.

So no other way other than re-running the FR24 signup script ?

John

[Oblivian]

It's not part of the Fr script. It's a config file that dump100 uses for parameters. Put it in the same line as the --net if that worked.

Sent from my XT1092 using Tapatalk

[milair]

Yes I realise that, and I haven't put in the --net command as I have no idea where it goes other than during the FR24 signup it does ask for additional arguments to add to Dump1090 if required - so I am thinking the easiest way to access it is to run the FR24 signup again ?? Or can I access the Dump1090 config file on it's own - where is it ??

Sorry to be so stupid

[Oblivian]

Errmm.. if --net wasnt specified somewhere already, your connection to 30002 wouldn't be going...


Adding it here should go.

settings.jpg

However if you have modified using a guide somewhere out there to make it a service and not connect to the USB stick on startup, it could be using one of 3 Dump1090, all which have different config files. And I'm running the Mutability one as a service, so can't tell you where the default FR24 one hides.

But as long as you use the same email and key etc, I see no reason --signup could do any bad if it asks for parameters. Its what everyone is having to do to switch to the new feed if they already have a key/ID

The Com/Dev may give better insight as to if its running background or spawned on launch of FR24feed

[milair]

Thanks, I'm not using 30002, only 30003 for VRS.

Must take more water with my whisky - didn't spot that line to add in the process arguments I think now would be a good time to retire, sorry if I have had you tearing your hair out

[Oblivian]

OK have been tinkering some more.

The installer for Pi is actually smarter than we give credit for

I have Piaware installed, but not currently running. Removed Dump1090, removed FR24feed

Installed per the single thread guide. Entered my existing details for re-signup.

We have detected that you already have a PiAware application instaled. We can therefore try to automatically configure the FR24 feeder to use existing receiver configuration, or you can manually configure all the parameters.

Would you like to use autoconfig (*yes*/no)$

Now I chose no at this point. As I wanted to replicate a bare-bones install where noone has fiddled and added other apps or feeders.

Step 4.2 - Please select dump1090 variant:

 1 - Malcolm Robb's fork (or another one that supports timestamps in the raw output)

Enter your connection type (1)$:1
Checking for dump1090...FOUND

Now I can only but surmise this occurred as it is bundled in the installer as I had previously removed.

And at this point, I played smarty and beat it to the punch. I enabled raw, and disabled BS output (can do this later in the web)

Step 4.3 - Enter your additional dump1090 arguments or leave empty
$:--net --net-http-port 8080

Now when I fired up the feeder in verbose mode (sudo fr24feed start) It spat me some errors:

[w]Detected --net argument for dump1090, disabling internal RAW feed!

(this has just turned off the setup page version)

Connecting to Generic receiver via (exe:///usr/lib/fr24/dump1090 --net --net-http-port 8080 --raw --mlat)

This is CALLING dump1090 to run after launch. Dump1090 has not been made a background process at this point - but some packages can make it.

It is including my chosen parameters and adding a default --raw and --mlat since I chose yes earlier during re-signup. But it is taking note of the setting and passing it. Good to find.

As for the location of Dump1090 it is launching. Default is
/usr/lib/fr24/dump1090

[Oblivian]

Thanks, I'm not using 30002, only 30003 for VRS.

Must take more water with my whisky - didn't spot that line to add in the process arguments I think now would be a good time to retire, sorry if I have had you tearing your hair out

In either case, net enables out going data You would be better to use the raw output, as not sure the basestation/30003 it has the MLAT tagging also Which they are getting close to being able to display on VRS when used with multi sources if I read correctly.

And no, not much hair to pull. I don't mind learning stuff for myself. Which is why I'm active on the Pi side of things at present. Pretty sure I got my head around the windows side so seem to be able to sort those pretty quick for people that don't stumble across the right posts

[milair]

All appreciated, I never used the windows version, so getting a Rpi and (trying) to learn Linux has been a steep curve. I was never into DOS, so that probably hasn't helped either. I have another RPi feeding MLAT data to the VRS server running different software so I only use the 30003 feed for a local copy of VRS on my PC.

I'll add the --net-http-port 8080 in on the option line and hopefully all will work.

John

[numbat]

FA = Flightaware
FR = Flightradar24

[...] The trouble is, and as obj has pointed out, even though the data is clearly distinguishable as MLAT data and not ADS-B data from dump1090, fr24feed just assumes it's ADS-B data because it has position information. Therefore, those T-feeders set up that way are sending MLAT positions to FR as ADS-B positions... So, instead of the data properly showing up as MLAT6 or MLAT7 it's show up as [some T-radar...].

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.

Stacey
T-KIZA1
Woodland Hills, California, US

[KK6LDW]

Indeed. I feel your pain, neighbor.

J.R.
T-KIZA3

[rodeo]

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

[numbat]

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

[numbat]

Feed no longer working

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

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:

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:

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.