Feeding data to Flight Radar24 and Flightaware at the same time-2020

[vobg1]

I'm using a Flightaware USB Pro Stick plus (Blue) and flight aware 1090MHz ads-b antenna. I have followed instructions on most of the posts on this forum regarding feeding data to multiple sites. I have tried the following,
1.On a fresh Fresh Raspbian buster Image, by running,

sudo bash -c "$(wget -O - http://repo.feed.flightradar24.com/install_fr24_rpi.sh)"

I get the following error,

pi@raspberrypi:~ $ sudo bash -c "$(wget -O - http://repo.feed.flightradar24.com/ install_fr24_rpi.sh)"
--2020-04-22 17:01:28-- http://repo.feed.flightradar24.com/install_fr24_rpi.sh
Resolving repo.feed.flightradar24.com (repo.feed.flightradar24.com)... 52.216.232.213
Connecting to repo.feed.flightradar24.com (repo.feed.flightradar24.com)|52.216.232.213|:80.. . connected.
HTTP request sent, awaiting response... 200 OK
Length: 1284 (1.3K) [text/x-sh]
Saving to: ‘STDOUT’

- 100%[================================================== ================================================== ================================================== =============>] 1.25K --.-KB/s in 0.001s

2020-04-22 17:01:33 (1.95 MB/s) - written to stdout [1284/1284]

Hit:1 http://archive.raspberrypi.org/debian buster InRelease
Hit:2 http://flightaware.com/adsb/piaware/files/packages buster InRelease
Hit:3 http://repo.feed.flightradar24.com flightradar24 InRelease
Hit:4 http://raspbian.raspberrypi.org/raspbian buster InRelease
Reading package lists... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
dirmngr is already the newest version (2.2.12-1+rpi1+deb10u1).
The following package was automatically installed and is no longer required:
libbladerf1
Use 'sudo apt autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 14 not upgraded.
Executing: /tmp/apt-key-gpghome.qZI2Q66W6d/gpg.1.sh --recv-key --keyserver pool.sks-keyservers.net C969F07840C430F5
gpg: keyserver receive failed: Server indicated a failure
Executing: /tmp/apt-key-gpghome.wk5KGDA5zD/gpg.1.sh --recv-key --keyserver pgp.mit.edu C969F07840C430F5
gpg: keyserver receive failed: Server indicated a failure

It says 0 upgraded, 0 newly installed, 0 to remove and 14 not upgraded because I had already tried it once and an older version is installed (not using the bash script though). But, this error was occuring on a fresh Raspbian image. Mainly,

Executing: /tmp/apt-key-gpghome.qZI2Q66W6d/gpg.1.sh --recv-key --keyserver pool.sks-keyservers.net C969F07840C430F5
gpg: keyserver receive failed: Server indicated a failure
Executing: /tmp/apt-key-gpghome.wk5KGDA5zD/gpg.1.sh --recv-key --keyserver pgp.mit.edu C969F07840C430F5
gpg: keyserver receive failed: Server indicated a failure

2. Tried installing fr24 on PiAware image. I get the same error, can't even go to the sign-up process!

3. Tried to install PiAware on a FR24 image. With dump1090-fa and dump1090-mutability enabled flight aware gets MLAT but FR24 does not enable MLAT. After removing dump1090-mutability, i observe the same behaviour as mentioned in the previous sentence. With dump1090-fa removed and dump1090-mutability installed, flightaware does not get MLAT, but FR24 does work fine.

4.Tried everything mentioned in point 3 with receiver changed to Mode-S Beast(TCP) instead of "dvbt" in FR24feeder config file which looks something like this,

bs="no"
raw="no"
mlat="yes"
mlat-without-gps="yes"
logmode="0"
receiver="beast-tcp"
host="127.0.0.1:30005"
procargs="--gain -10"
fr24key="xxxxxxxxxxxxxx"

with the above config file suggested on these forums (to feed piaware and fr24), FR24 also does not run with MLAT enabled or does not upload anything.

With the below config file,FR24 runs with MLAT enabled and works fine.

bs=yes
raw=yes
mlat="yes"
mlat-without-gps="yes"
logmode="0"
procargs="--gain -10"
fr24key=xxxxxxxxxxxxx
receiver="dvbt"

The fact that,

sudo bash -c "$(wget -O - http://repo.feed.flightradar24.com/install_fr24_rpi.sh)"

is giving an error as shown above in this post is what is preventing me from following most guides on this forum to go about uploading data to FR24 and FlightAware!
How do I go about solving this issue? Any suggestions are very much appreciated! Thanks in advance!

[Khan]

FR24 only uses MLAT data if in the config receiver type is dvbt. If is anything else, MLAT data is not used. If you already have FR24Feed installed, you don't need to install it again. If it is not and the script is returning an error, you can manually download the deb file and install it.

wget https://repo-feed.flightradar24.com/...25-3_armhf.deb
sudo dpkg -i fr24feed_1.0.25-3_armhf.deb
sudo fr24feed --signup

[Oblivian]

Wasn't opening the feeder up to using different versions of Dump1090 the whole idea of allowing MLAT from a greater userbase since it can add timetagging to different data formats that support it?

2020-04-23 23:14:52 | [main][i]Socket server started
2020-04-23 23:14:52 | [bs][i]Initializing server
2020-04-23 23:14:52 | [bs][i]Starting server on 0.0.0.0:30003
2020-04-23 23:14:52 | [reader][i]Connecting to unknown receiver via (tcp://127.0 .0.1:30005)

In my case, beastsplitter raw with timetagging from ModeSBeast

2020-04-23 23:14:52 | [mlat][i]Waiting for MLAT configuration
2020-04-23 23:14:52 | [main][i]MLAT data feed started
2020-04-23 23:14:52 | [reader][i]Connected to the receiver, configuring
2020-04-23 23:14:52 | [reader][i]Configured, processing messages
2020-04-23 23:14:52 | [reader][i]Timestamp source changed from UNKNOWN to SYSTEM -UNCERTAIN
2020-04-23 23:14:53 | [time][i]Synchronizing time via NTP

...

2020-04-23 23:14:55 | [mlat][i]MLAT configuration received, service ENABLED
2020-04-23 23:14:55 | [mlat][i]Starting MLAT with preconfigured position: -43.36,172.67,25.0
2020-04-23 23:14:55 | [mlat][i]MLAT bandwidth reduction active, level 1
2020-04-23 23:14:55 | [mlat][i]Configuring UDP connection udp://australia.fr24.com:19788
2020-04-23 23:14:55 | [mlat][i]Registering MLAT station
2020-04-23 23:14:55 | [mlat][i]Registering MLAT station: SUCCESS
2020-04-23 23:14:56 | [feed][n]connected via TCP (fd 16)
2020-04-23 23:14:56 | [feed][i]Feed connected
2020-04-23 23:14:56 | [feed][n]working
2020-04-23 23:14:57 | [feed][i]sent 1,0 AC
2020-04-23 23:15:02 | [feed][i]sent 2,0 AC
2020-04-23 23:15:02 | [mlat][e]Received MLAT timestamp error: 0 seconds!
2020-04-23 23:15:02 | [mlat][i]Received ADS-B time references AC:
2020-04-23 23:15:02 | [mlat][i] C82396
2020-04-23 23:15:02 | [mlat][i] C828BB
2020-04-23 23:15:07 | [feed][i]sent 2,0 AC
2020-04-23 23:15:12 | [feed][i]sent 2,0 AC
2020-04-23 23:15:13 | [mlat][i]Pinging the server
2020-04-23 23:15:13 | [mlat][i]Stats 6425629/6425629
2020-04-23 23:15:17 | [feed][i]sent 2,0 AC
2020-04-23 23:15:23 | [feed][i]sent 2,0 AC

Perhaps time to get the software to report differently or hard-code the message somewhere so it's obvious then.
So people don't use it as a fault finding or freak out like they do since it is in your face 'DOWN' status on fr24feed-status

[abcd567]

FR24 only uses MLAT data if in the config receiver type is dvbt. If is anything else, MLAT data is not used

Thanks Khan for the info. I never knew this.

[ylis]

So now I'm confused. All the advice in the Forum was not to use receiver=dvbt. I was using receive=avr-tcp and host=127.0.0.1:30002 until recently when I changed to beast-tcp and 30005.

Can someone (Oblivian / abcd567 / wiedehopf ) publish a summary of the reasons for and against using each setting. Happy if this is restricted to feeding FR24 in this forum as layering mulitple feeds adds to the complications / confusion.

Thanks

[Oblivian]

You're as confused as me

When everyone says mlat is down the first fix is to use beast binary (if not the only feed and set to dvbt) which is tagged with mlat timestamps.

If they've decided it tells you the format is valid via status but not being used then that's not on us.

Majority aren't going to limit to 1 feed. And when the fr24 feeder doesn't support multiple tcp connectors downstream or crashes/restarts regular even i moved away from it being the primary feed.

So be it i guess. We've been lead wrong all along it seems.

Guess the reliance is more on their own feeders than the rest of us needing to bother.

[abcd567]

If Flightradar24 has decided to restrict MLAT to only setting "receiver=dvbt", then no problem. If I have installed dump1090 (mutab or fa) myself, I will simply uninstall it, then change fr24feed setting from receiver="beast-tcp" or receiver="avr-tcp" to receiver="dvbt", and restart fr24feed. The fr24feed will then install dump1090-mutability, and start feeding FR24 and MLAT will also start functioning ok.

However with setting "receiver=dvbt", fr24feed will configure dump1090-mutability to block output ports 30003 and 30005, causing failure of feeds to Flightaware, Planefinder, Radarbox24 etc.

The above problem can very easily be solved by adding --net in the "Process arguments" field on settings page (ip-of-pi:8754/settings.html) or adding it in file "/etc/fr24feed.ini" in the following line:
procargs="--net --gain -10"

After above modifications, restart fr24feed, and dump1099-mutability will open port 30005 and start supplying data to Flightaware, Planefinder, Radarbox24 etc.

[Oblivian]

That's just it. There is nothing saying it restricts it.

It always says OK when using binary. Look at my log, and I don't have a dvbt.

But users still see 'mlat:down' when setting up for the first time and come here for help and ask why where they want guidance.

Telling them the output to get it to accept and appear it was working was what we were all lead to believe was valid until now.

If its as stupid as it now sounds, remove the status references. Stop the confusion.

[abcd567]

If its as stupid as it now sounds, remove the status references. Stop the confusion.

Fully agreed

[riderz49]

So, is it not possible to configure the receiver to simultaneously use both the MLAT and non-MLAT data? Or am I missing something.

And more importantly, are there any instructions for configuring the system for both the fr24 and fa interfaces?

[wiedehopf]

FR24 does not provide you with MLAT results on your receiver.

[abcd567]

Users dont get MLAT data feed back from FR24, RB24, and many other sites. Therefore for a user feedeing these sites, it does not give any advantage if MLAT is working, or any disadvantage if MLAT is not working. Users should realize this and stop bothering about MLAT on these sites. If it works it is ok, if it does mot work it is still ok.

On the contrary, the Flightaware and Adsbexchange provide MLAT feed back to users which is fed to port 30104 of dump1090 (mutability & fa versions), and the mlat planes are displayed on local map (ip-of-pi/dump1090/ for dump mut, and ip-of-pi/dump1090-fa/ for dump fa). In these two sites enabling mlat is advantageous to the user as well.


If someone is using Pi24 image, it has by default:

dump1090-mutability is pre-installed
in settings:
receiver="dvbt"
mlat="yes"
mlat-without-gps="yes"

As a result mlat of FR24 is enabled by default.

However Pi24 does not make dump1090-mutabilty's beast format data at port 30005 for use by other feeders like Flightaware & Radarbox24. This can very easily be overcome by adding --net to procargs= line in /etc/fr24feed.ini to make it like this
procargs="--net --gain -10"

[Oblivian]

Which is the stupid thing

Cause watch the command line if you stop service and run not in service mode what it does.

Launches dump1090 with a command line after it (just like it would in service mode if you specify options) yet apparently the uploader thread can only use mlat tagged binary data if 'dvbt' and not commandline + tcp out?!? (But still tells you it is)

[riderz49]

You wrote the it's irrelevant, when using fr24, whether MLAT is or is not working. Wouldn't it be appropriate to disable if it's working, to free any resources it might be using--like fixing a dripping faucet?

[Oblivian]

No resources change. All it does is confirm the ones with no gps data has ntp timestamp applied, and bundle with 2x reference gps adsb contacts also received and send.

Server does the work.

It only benefits fr24/the map. Not us. No harm, no foul. But all the status/logs etc go nuts if mlat isn't functioning as expected. Which is why we are all stumped. If server can't use it in anything other than dvbt as we're now told, why show it to users as working with modesbeast like I have and beast-tcp setting too.