Archived - Beta test MLAT software for Raspberry Pi

[bhaal]

Hi guys,

We're pleased to announce new beta version of the feeder software (1.0.14-9) that is no longer bound to our own dump1090 build.
Included dump1090 is now Malcolm Robb's fork and I would kindly ask you to also test how it works with other forks that you may wish to use and provide a feedback.

Thanks,
Flightradar24 team

Very nicely done vinny!!! I hadn't followed this thread for a few days, it's nice to get pleasant surprise when I jump back in! I've updated, turned mlat back on.. Using mutability as I was previously, and it seems to be working just fine from what I can see.

Any chance in the future that we will get mlat position feedback so we can view via a basestation/beast network port (to connect with VRS)? That would be awesome as well.. Either way, happy to feed Mode-S data now as it doesn't increase load like it did before.

Good work!!! Thanks

[Tviki]

Online again!!! Just installed Malcolm Robb dump1090

[giacomo892]

Is mlat working using other feeder rather than the default one like mutability one or am I just feeding mode s?

[jb_bak]

Is mlat working using other feeder rather than the default one like mutability one or am I just feeding mode s?

Yes.. this question!

[jb_bak]

Also, can anyone help me with setting up my /etc/fr24feed.ini file? I'm mainly just a FA feeder.
I already have 3 instances of dump1090-mulitibilty running on a RPi2. All have the --mlat enabled.
I would like to feed the beast output from all three dump1090 instances(or maybe just the output of the main dump1090 that others feed??) to fr24feed (not using any dongles directly). I am currently feeding the two dongles to the main feed using nc, which works. Just not sure what reciever type or how to enable fr24feed to listen on a nonstandard port for beast input in the fr24feed.ini file.

Here are my current dump-1090 settings for the three instances running, with the last one being the master version getting data from the first two:

dump1090-mutability --mlat --quiet --net --interactive-ttl 300 --modeac --lat <edited> --lon <edited> --phase-enhance --gain -10 --ppm 26 --device-index 1 --net-bo-port 31007 --net-bi-port 0 --net-ro-port 0 --net-ri-port 0 --net-sbs-port 0 --net-http-port 0 --net-fatsv-port 0

dump1090-mutability --mlat --quiet --net --interactive-ttl 300 --modeac --lat <edited> --lon <edited> --phase-enhance --gain -10 --ppm 30.920 --device-index 2 --net-bo-port 31006 --net-bi-port 0 --net-ro-port 0 --net-ri-port 0 --net-sbs-port 0 --net-http-port 0 --net-fatsv-port 0

# dump1090-mutability configuration file
# This is a POSIX shell fragment.
# You can edit this file directly, or use
# "dpkg-reconfigure dump1090-mutability"

# Set to "yes" to start dump1090 on boot.
START_DUMP1090="yes"

# User to run dump1090 as.
DUMP1090_USER="dump1090"

# Logfile to log to
LOGFILE="/var/log/dump1090-mutability.log"

#
# Receiver options
#

# RTLSDR device index or serial number to use
# If set to "none", dump1090 will be started in --net-only mode
DEVICE=""

# RTLSDR gain in dB.
# If set to "max" (the default) the maximum supported gain is used.
# If set to "agc", the tuner AGC is used to set the gain.
GAIN="max"

# RTLSDR frequency correction in PPM
PPM="0"

# If yes, enable sampling at 2.4MHz. Otherwise, 2.0MHz is used.
OVERSAMPLE="yes"

# If yes, enables phase-enhancement of messages
PHASE_ENHANCE="yes"

#
# Decoding options
#

# If yes, fixes messages with correctable CRC errors.
FIX_CRC="yes"

# If yes, enables aggressive fixes to damaged messages.
# Use with caution - it can increase the rate of undetected errors.
AGGRESSIVE="no"

# If set, supplies a reference location for local position decoding.
LAT="<edited>"
LON="<edited>"

# If set, provides the absolute maximum receiver range used to
# filter bad position reports, and to determine when local position
# decoding is safe to use. Specify this in nautical miles (NM).
MAX_RANGE="300"

#
# Networking options
#

# Port to listen on for HTTP connections. 0 disables.
# HTTP defaults to being disabled unless you specify something here. I 
# that you do not enable this, and instead serve the contents of
# /usr/share/dump1090-mutability and JSON_DIR (below) using a proper
# webserver. See /etc/lighttpd/conf-available/90-dump1090.conf
# for an example configuration ("sudo lighty-enable-mod dump1090" to enable)
HTTP_PORT="0"

# Port to listen on for raw (AVR-format) input connections. 0 disables.
RAW_INPUT_PORT="30001"

# Port to listen on for raw (AVR-format) output connections. 0 disables.
RAW_OUTPUT_PORT="30002"

# Port to listen on for SBS-format output connections. 0 disables.
SBS_OUTPUT_PORT="30003"

# Port to listen on for Beast-format input connections. 0 disables.
BEAST_INPUT_PORT="30004"

# Port to listen on for Beast-format output connections. 0 disables.
BEAST_OUTPUT_PORT="30005"

# Port to listen on for FATSV-format output connections. 0 disables.
FATSV_OUTPUT_PORT="10001"

# TCP heartbeat interval in seconds. 0 disables.
NET_HEARTBEAT="60"

# Minimum output buffer size per write, in bytes.
NET_OUTPUT_SIZE="500"

# Maximum buffering time before writing, in seconds.
NET_OUTPUT_INTERVAL="1"

# TCP buffer size, in bytes
NET_BUFFER="262144"

# Bind ports on a particular address. If unset, binds to all interfaces.
# This defaults to binding to localhost. If you need to allow remote
# connections, change this.
NET_BIND_ADDRESS=""

#
# Misc options
#

# Interval (in seconds) between logging stats to the logfile. 0 disables.
STATS_INTERVAL="3600"

# Path to write json state to (for use with an external webserver). Blank disables.
JSON_DIR="/run/dump1090-mutability"

# Interval between writing json state (in seconds). 0 disables.
JSON_INTERVAL="1"

# Accuracy of receiver location to write to json state, one of "exact" / "approximate" / "none"
JSON_LOCATION_ACCURACY="approximate"

# Set to yes to log all decoded messages
# This can get large fast!
LOG_DECODED_MESSAGES="no"

# Additional options that are passed to the Daemon.
EXTRA_ARGS="--mlat --net --net-http-port 8080"

And the nc scripts:

#!/bin/sh
sleep 20
while :
do
  nc -d localhost 31006 | nc -q1 localhost 30004
  sleep 15
done

#!/bin/sh
sleep 10
while :
do
  nc -d localhost 31007 | nc -q1 localhost 30004
sleep 15  
done

T-VHHH55 http://bobsaget.mooo.com:8080

[Kpin]

I have been following one aircraft I know not to be ADS-B equipped flying along the north coast of The Nederlands, and clearly some of the Raspberry Pi feeders are feeding Flight Aware calculated positions back into FR24.

So fare I have seen T-EHAM63 and T-EHSB7 shown as the radar for this aircraft (OY-EUR). Something should be done to weed these position reports out.

[yonailo]

Hello, I am feeding with a Raspbery PI 2 + MLAB feature.

Reading this post it seems to be a problem the fact that Raspberry PI does not have a hardware clock, as far as I understand having NTP is not enough.

Would things be better if we buy a hardware clock, like the mini rtc clock ?

If this could improve things, I would be ready to buy it.

[cbgsy]

Using an RTC clock would be unlikely to improve things as far as I'm aware.

The main issue is the relative offset from true UTC for each of the units which is why internet NTP doesn't improve things - it's very dependent on network delay and jitter (variation in delay). FR24 gets around this by calculating the relative offset for PI feeders by comparing the timestamps and arrival times for a known Mode-S packet containing a definite position. It effectively performs the MLAT calculation on that packet, then reverse-engineers the relative offsets of the PI stations to get the best match between that and the real position. Any other packets received at a similar time (in the order of seconds) can be reasonably safely assumed to have the same offset before the clock drifts, so the system is self-adjusting. In theory the clocks could be out by hours or days and still work.

I personally use a PPS-enabled GPS module to feed NTP on my PI. This won't stop FR24 calculating the offset from my data feed, but at least I know it will (or should) be consistently reasonably close to zero so may help improve accuracy.

See http://www.ebay.co.uk/itm/New-Ublox-...-/161648903960 for a similar module to mine. The PPS output isn't presented on the pin-header on this unit, but you can easily solder a wire to it.

There's some good information on the following links on how to configure things:

http://ntpi.openchaos.org/pps_pi/
http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html

The only trouble is that the module needs to be outside to get a signal and the PI relatively close. Mine is currently out in a weather-proof box together with the RTL dongle which works well. However, this week's project is to change over to an external GPS antenna and move the PI back indoors, since my 5V PSU for the PI sprays interference right across my VHF reception on airband, marine and NOAA / Meteor Sats as the antennas are nearby on the roof

HTH

[Kpin]

Getting confused about the status I get from the feeder...

How does the lines
"FR24 Tracked AC: nn"
and
"FR24 MLAT AC seen: mm"
relate to oneanother?

Sometimes the numbers are the same, and sometimes they are different but always similar.
RPI Status.JPG

Initially i thought 'tracked' referred to ADS-B aircraft and 'MLAT seen' to MLAT contribution, but the numbers seems related in some way.

[cbgsy]

Looking forward to the Guernsey Air Display, this Thursday, 10th Sept.

My PI MLAT feeder has clear coverage right in front of the display zone, so will be a good test for other low-altitude coverage in the area to see if we can pick anything up on FR24.

See http://www.guernseyairdisplay.com/#!programme/ckqh for details (all times UK / BST)

[patrick1501]

I upgraded to the latest version, and everything works.
But how do I check which version of fr24feed and dump1090 I am running?

[rodeo]

Sat down this morning and changed things around a bit here.

Am now running dump1090-mutability and the latest versions of FR24Feed and FA.

All seems to be co-habiting OK at the moment and all are happy.

[Flash]

Updated to last version (14.11) today and working fine for me:

[ ok ] FR24 Feeder/Decoder Process: running.
[ ok ] FR24 Stats Timestamp: 2015-09-12 15:26:08.
[ ok ] FR24 Link: connected [UDP].
[ ok ] FR24 Radar: T-EDDL39.
[ ok ] FR24 Tracked AC: 12.
[ ok ] Receiver: connected (21690 MSGS/0 SYNC).
[ ok ] FR24 MLAT: ok [UDP].
[ ok ] FR24 MLAT AC seen: 11.

[North Borneo Radar]

I upgraded to the latest version, and everything works.
But how do I check which version of fr24feed and dump1090 I am running?

Would hope to have answers for this question too please.

[Oblivian]

Would hope to have answers for this question too please.

Use the onboard web-browser, and check log when launching.

http://<feederdevicelocalip>:8754/monitor.txt

Should show similar to:

ac_map_size="2048"
build_arch="i386"
build_flavour="generic"
build_os="Windows"
build_revision="284"
build_timetamp="Sep 7 2015 14:19:56"
build_version="1.0.14-9"