Archived - Beta test MLAT software for Raspberry Pi

[Oblivian]

I am running dump1090 (mutability fork) on RTL dongle, with --net option activated. In fr24feed I configured receiver selection for option 4 - ModeS Beast and connection type Network connection. Finally I specified IP and port of data feed (default 30005 on dump1090) and disabled all data forwarding options to avoid conflicts with dump1090.

In past, I had to run this configuration due to characteristics of my setup (ADS-B decoder and fr24feeder had to run on separate devices), currently it is mainly due to extended functionality of dump1090-mutability fork compared to FR24 fork.

Odd. But good to know that combo works

The norm would be use the AVR-TCP selection and out of dump1090 instead on 30002

Not sure if dump1090 changes the beast output timestamps in a way that the MLAT upload portion will agree with.

[MaCo]

Odd. But good to know that combo works

The norm would be use the AVR-TCP selection and out of dump1090 instead on 30002

Not sure if dump1090 changes the beast output timestamps in a way that the MLAT upload portion will agree with.

Good to know that AVR-TCP in fr24feed is the same format as RAW in dump1090. If I had known this, I would be using that configuration from the beginning

One thing to mention - on mutability fork, default ports for RAW input and output are swapped compared to other forks (RAW output defaults to 30001).

I'll continue with RAW feed then. Thanks again for your help.

[Oblivian]

Has reminded me to add note re 30001. It's a pipe port. What goes in, goes out. Which could be dangerous (and possibly the reason for some feeders multiplexing feeds and sending position data from other sources)

[Sam26K]

Any word on when FR24 will sort out pi MLAT for FR24? Is there still a timing issue holding it up?

[Olov]

Any word on when FR24 will sort out pi MLAT for FR24? Is there still a timing issue holding it up?

That is something that we work very hard on to bring back. I don't want to say when, but certainly as soon as possible!

It's not a timing issue, more of a data volume issue.

[Sam26K]

That is something that we work very hard on to bring back. I don't want to say when, but certainly as soon as possible!

It's not a timing issue, more of a data volume issue.

Looking forward to the return of FR24 MLAT and appreciate your teams efforts. Glad to hear it's not a timing issue.

IMHO your major issue is trust in the source of the data. There should be a ranking based on "trust". It shouldn't be difficult to flag feeders that are leaking MLAT based data. If most of the feeders in a given area are not returning GPS data on an a/c and 1 feeder is feeding gps data for every a/c in the area, those feeders could be flagged to a much lower rank and less reliable source of data.

Thanks again and looking forward to FR24 for pi returning soon! .

[Sam26K]

BTW, not to beat a dead horse, but T-KSJC18 and T-KSJC12 are the worst MLAT leaks in the San Francisco bay area if not the world And they have no shame. My personal theory is that are intentionally "dithering" the feed to make it less accurate.

[dvlachio]

I have installed the new raspberry pi software version of 03.03.2016. The receiver is sbs1 via tcp network link.
I think there is a problem. Previous version was working ok.
Thanks in advance

here is the output
[ ok ] FR24 Feeder/Decoder Process: running.
[ ok ] FR24 Stats Timestamp: 2016-03-03 19:52:47.
[FAIL] FR24 Link: connecting ... failed!
[ ok ] Receiver: connected (211631 MSGS/0 SYNC).
[FAIL] FR24 MLAT: not running ... failed!

[piopawlu]

Wait a while after you restart the service, it works just fine here, but you need to give it a minute to update status file.

[KarlNapf]

My RPi auto-updated to 18.4 tonight, nothing else changed on my side.
This version now uses TCP for ADS-B (8099) and continues using UDP for MLAT (19788).
Prior versions used UDP for both, ADS-B and MLAT. Is this intended?

The feeder-sw first tries UDP, the packet is definitely sent.
No response from the FR24 side is received for 20 seconds
and the feeder-sw switches to TCP. The SYN is ACKed immediately.

[piopawlu]

Previous version always used TCP for ADS-B first, and then switched to UDP. The new version tries UDP, but the current server does not yet have this option enabled, it will be available early next week. So yes, this is intended,, in the end there will be no TCP connection unless UDP fails.

[Swen]

Need to get 990 kB/1,480 kB of archives.
After this operation, 1,024 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://ports.ubuntu.com/ubuntu-ports/ trusty-updates/main libjasper-dev armhf 1.900.1-14ubuntu3.3 [499 kB]
Get:2 http://ports.ubuntu.com/ubuntu-ports/ trusty-updates/main libjasper1 armhf 1.900.1-14ubuntu3.3 [110 kB]
Get:3 http://ports.ubuntu.com/ubuntu-ports/ trusty-updates/main libpixman-1-dev armhf 0.30.2-2ubuntu1.1 [174 kB]
Get:4 http://ports.ubuntu.com/ubuntu-ports/ trusty-updates/main libpixman-1-0 armhf 0.30.2-2ubuntu1.1 [159 kB]
Get:5 http://ports.ubuntu.com/ubuntu-ports/ trusty-updates/main ifupdown armhf 0.7.47.2ubuntu4.4 [48.6 kB]
Fetched 990 kB in 2s (451 kB/s)
(Reading database ... 192879 files and directories currently installed.)
Preparing to unpack .../fr24feed_1.0.18-5_armhf.deb ...
* Stopping FR24 feeder fr24feed
Killing all children processes
[ OK ]
Unpacking fr24feed (1.0.18-5) over (1.0.16-11) ...
update-rc.d: /etc/init.d/fr24feed exists during rc.d purge (use -f to force)
dpkg: warning: subprocess old post-removal script returned error exit status 1
dpkg: trying script from the new package instead ...
update-rc.d: /etc/init.d/fr24feed exists during rc.d purge (use -f to force)
dpkg: error processing archive /var/cache/apt/archives/fr24feed_1.0.18-5_armhf.deb (--unpack):
subprocess new post-removal script returned error exit status 1
update-rc.d: /etc/init.d/fr24feed exists during rc.d purge (use -f to force)
dpkg: error while cleaning up:
subprocess new post-removal script returned error exit status 1
Preparing to unpack .../libjasper-dev_1.900.1-14ubuntu3.3_armhf.deb ...
Unpacking libjasper-dev (1.900.1-14ubuntu3.3) over (1.900.1-14ubuntu3.2) ...
Preparing to unpack .../libjasper1_1.900.1-14ubuntu3.3_armhf.deb ...
Unpacking libjasper1:armhf (1.900.1-14ubuntu3.3) over (1.900.1-14ubuntu3.2) ...
Preparing to unpack .../libpixman-1-dev_0.30.2-2ubuntu1.1_armhf.deb ...
Unpacking libpixman-1-dev (0.30.2-2ubuntu1.1) over (0.30.2-2ubuntu1) ...
Preparing to unpack .../libpixman-1-0_0.30.2-2ubuntu1.1_armhf.deb ...
Unpacking libpixman-1-0:armhf (0.30.2-2ubuntu1.1) over (0.30.2-2ubuntu1) ...
Preparing to unpack .../ifupdown_0.7.47.2ubuntu4.4_armhf.deb ...
Unpacking ifupdown (0.7.47.2ubuntu4.4) over (0.7.47.2ubuntu4.3) ...
Processing triggers for man-db (2.6.7.1-1ubuntu1) ...
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)

This happens again and again. So i must remove package and then i can reinstall it... Thats not funny. Do am i something wrong or there must be a bug in update script from the package?!

[Oblivian]

This happens again and again. So i must remove package and then i can reinstall it... Thats not funny. Do am i something wrong or there must be a bug in update script from the package?!

Try this..

http://forum.flightradar24.com/threads/9964-Unable-to-uninstall-purge-fr24feed_1-0-13-2_i386-deb-after-try-to-install-new-version?p=76036&viewfull=1#post76036

[Sam26K]

Just for positive feedback, the pushed update is working fine for me and feed status on FR24 shows no interruptions since the last time I updated it manually about 4 days ago .

[Swen]

Try this..

http://forum.flightradar24.com/threa...ll=1#post76036

Yes i know, get two sides back in this thread and you will find our discussion about it. But it's not ok if i must reinstall by hand. Then we don't need a package management. The other worse side is that package management will be interrupt in update process... DEB package for easy installation is one side of the coin the other side is to get a valid update or upgrade process.