On my stats page it shows that my mlat is synced with around 350 nearby receivers.
I know ADSBEXCHANGE.COM has a web page listing somewhere that lists something to do with mlat synchronisation so am curious, I thought mlat just needed 3 or 4 stations to position so what is the benefit of syncing with so many?
Plus, I’m guessing that the 350 with which I am synced cant all be close by so how far away might these other stations be?
Geoff
This is reporting receivers that you have clock synchronization with. Synchronizing the clocks is the first step and is necessary before any actual multilateration can be done, and it’s not predictable which receivers will actually see copies of a particular message that needs multilateration, so it makes sense to do it with as many nearby receivers as possible ahead of time.
What is the effective maximum distance two receiverscan be separated and still synchronise?
Thanks,
S
Several hundred NM. The requirement is that both receivers can see the same ADS-B-transmitting aircraft.
How does it determine which devices to sync with?
Geoff
The server “knows” your reported location… and, like Obj said above, if the timings are correct… you have a match.
MLAT is less and less important. The number of MLAT flights already dropped a lot in US, and it’s not even 2020. I think it’s the same in EU and Australia.
Most general aviation aircraft don’t have ADS-B in Europe, and UAT doesn’t exist here at the moment. I’m still seeing 5-600 mlat aircraft a day, with a further 500 or so mode-s only aircraft here. That’s with syncing 700 stations, so mlat will be relevant for some time here I think.
All receivers in the same mlat region (i.e. handled by the same server instance) try to sync with each other. This can be a few thousand receivers. The receivers aren’t involved in the decision, they just get told what traffic to forward.
When I started this hobby in summer of 2017, in US, the MLAT traffic was approximate 1/3 of total traffic.
Now is less than 1/10; yesterday I had 2800 ADS-B planes and 240 MLAT.
I think ads-b was less common in the US initially though so there will be a more noticeable change there. I haven’t noticed a big increase in the number of ads-b aircraft compared to mode-s only here, but I don’t have data going back to compare it for sure. There is also a mandate for larger aircraft to have ads-b installed by June next year here, so it will be interesting to see what changes between now and then.
I’m also curious to see if there will be an increase in the number of mlat positions I get when I move my antenna to the roof later this week. From plots I made of mlat results, there are significant gaps in coverage at the moment.
Here even the trainer planes have ADS-B now, I am watching them on ADS-B versus UAT, and they are not there.
Some private jet planes now turn off ADSB so they won’t be tracked. Is MLAT still important for tracking these?
They don’t turn off ADS-B but request to be blocked on the tracking websites. ADS-B is mandatory, only exception are military aircraft.
A working transponder is a required item for an aircraft just like a comm radio to maintain contact with ATC. Even if you are a superstar or celebrity 
And while they might be blocked on a tracking website they will still be visible when coming in to range of a local tracking station. The local view doesn’t filter, that happens after the data has been sent to the server.
I faced problem of mlat not synchronized when piaware & dump1090-fa were installed in Debian running in Oracle VM on Windows PC. The passthrough of dongle from Windows to VM made clock unstable.
I solved this problem by installing dump1090-win on Windows PC, so there was no problem of dongle passthrough as the dongle was directly accessible to dump1090-win.
In order to transfer data from dump1090-win to dump1090-fa, I created a puller service which used socat TCP connection between two dump1090s. In dump1090-fa’s config file, I had to change RECEIVER=rtlsdr to RECEIVER=none to run it in net mode without any dongle.
Below are full details of what I did;
(1.1) Downloaded dump1090-win from github to Windows PC
https://github.com/MalcolmRobb/dump1090/raw/master/dump1090-win.1.10.3010.14.zip
(1.2) Unzipped the downloaded folder.
(1.3) Entered the unzipped folder. Inside this folder there is a file named dump1090.bat. Double clicked it to start dump1090-win. When done first time, I was asked permission to run it, which I gave. This started a command prompt displaying aircraft data,as shown in screenshot below.
(2.1) Installed package socat
(2.2) Created necessary folder and file to run the socat TCP connection between dump1090-win and dump1090-fa
sudo apt install socat
sudo mkdir /usr/share/puller
sudo touch /usr/share/puller/puller.sh
sudo chmod +x /usr/share/puller/puller.sh
sudo nano /usr/share/puller/puller.sh
Copy-pasted following code in newly created blank file /usr/share/puller/puller.sh
NOTE: In line SOURCE_IP="192.168.12.6", replace 192.168.12.6 by IP address of your Windows Computer on which you are running the dump1090-win
#!/bin/bash
SOURCE_IP="192.168.12.6"
OPTIONS="keepalive,keepidle=30,keepintvl=30,keepcnt=2,connect-timeout=30,retry=2,interval=15"
while true
do
echo "CONNECTING TO: dump1090-windows"
socat --experimental -dd -u TCP:${SOURCE_IP}:30005,${OPTIONS} TCP:127.0.0.1:30004,${OPTIONS}
echo "LOST CONNECTION TO: dump1090-windows"
sleep 60
done
(2.3) Created systemd service to run the puller script
sudo nano /lib/systemd/system/puller.service
In the newly created blank service file /lib/systemd/system/puller.service, copy-paste following code
# puller service for systemd
[Unit]
Description=puller service
Wants=network.target
After=network.target
[Service]
##User=puller
RuntimeDirectory=puller
RuntimeDirectoryMode=0755
ExecStart=/usr/share/puller/puller.sh
SyslogIdentifier=puller
Type=simple
Restart=on-failure
RestartSec=30
RestartPreventExitStatus=64
Nice=-5
[Install]
WantedBy=default.target
Enable and start the puller
sudo systemctl enable puller
sudo systemctl start puller
(2.4) Edited file /etc/default/dump1090-fa and changed RECEIVER=rtlsdr to RECEIVER=none.
Saved file and restarted dump1090-fa
sudo systemctl restart dump1090-fa
Click on Screenshot to See Larger Size
Under item (2), carryout only step (2.4) to run dump1090-fa in net-only mode, and omit steps (2.1), (2.2), & (2.3) which pertain to creation of `socat TCP connector “puller”. Instead issue following commands which will enable piaware to create a connection directly to dump1090-win.
NOTE: in the command below, change 192.168.12.6 to IP of your Windows computer running dump1090-win.
sudo piaware-config receiver-type other
sudo piaware-config receiver-port 30005
sudo piaware-config receiver-host 192.168.12.6
sudo systemctl restart piaware
Although dump1090-win provides a map in browser in Windows PC at following address:
localhost:8080
but it has Google map with water marks. Also, in some browsers, map will not show, only 2 clocks at top-right corner. This is caused by format of files in unzipped folder dump1090-win/public_html being in DOS/Windows format (CRLF) indtead of Unix (LF). I used Notepad++ to change Windows {CRLF) to Unix (LF), and map started working OK.
