Will network data sources cause MLAT synchronization to fail?

[baiqi]

A few hours ago, I ran a dump1090 on my router in the north room and sent the data to raspberry pi (port 30004) on the south to improve coverage in the northwest. The two antennas are about 10m apart. But when I just checked the FA page, I saw the MLAT logo turn red.

The log prompts an error: clock unstable

Jan 21 14:17:12 LATDP-0x00 piaware[434]: mlat-client(2921): Receiver status: connected
Jan 21 14:17:12 LATDP-0x00 piaware[434]: mlat-client(2921): Server status:   clock unstable
Jan 21 14:17:12 LATDP-0x00 piaware[434]: mlat-client(2921): Receiver:  250.0 msg/s received       81.3 msg/s processed (33%)
Jan 21 14:17:12 LATDP-0x00 piaware[434]: mlat-client(2921): Server:      0.0 kB/s from server    0.0kB/s TCP to server     0.4kB/s UDP to server
Jan 21 14:17:12 LATDP-0x00 piaware[434]: mlat-client(2921): Aircraft: 0 of 12 Mode S, 6 of 28 ADS-B used
Jan 21 14:18:43 LATDP-0x00 piaware[434]: 498568 msgs recvd from dump1090-muta (483 in last 5m); 497382 msgs sent to FlightAware
Jan 21 14:20:40 LATDP-0x00 piaware[434]: mlat-client(2921): Accepted Beast-format results connection from ::1:47972
Jan 21 14:20:42 LATDP-0x00 piaware[434]: mlat-client(2921): Beast-format results connection with ::1:47972: connection lost
Jan 21 14:20:47 LATDP-0x00 piaware[434]: mlat-client(2921): Accepted Extended Basestation-format results connection from ::1:53338
Jan 21 14:20:50 LATDP-0x00 piaware[434]: mlat-client(2921): Extended Basestation-format results connection with ::1:53338: connection lost

I have determined that both devices have correct system time.
Is there any way to solve this problem?

[baiqi]

I saw this in the log:

Warning: the timestamps provided by your receiver do not seem to be self-consistent. This can happen if you feed data from multiple receivers to a single mlat-client, which is not supported; use a separate mlat-client for each receiver.

The current architecture is like this:

I think if change to the following, should be able to get more ADS-B coverage while retaining MLAT

However, PiAware does not seem to support setting a separate data acquisition port for MLAT-Client.

Any suggestions?

(A little Mistake, need to change “RPI North” to “Router North”)

[david.baker]

The beast data has microsecond timing in the ADSB message based on the receiver clock (RTL dongle or prostick internal clock). So The RPI south and RPI north will have different microsecond timing in the messages based on the receiver’s clock. These clock are not synchronized so there is no easy way to know the absolute clock timing on your side and you CAN’T mix them before sending them to FlightAware.

Once a message reaches FlightAware the clock timing are synchronized. We use the site ID as a message bin and the clocks in each bin should be consistent of the same microsecond timing. So if you mix the two receiver data then your site will be kicked off MLAT for having inconsistent clock values in the same bin.

To connect this for MLAT you would need to have each RPI South and RPI north connect back to FlightAware with their own Site ID. You will then get the MLAT return data which then can be used for you own purposes.

I suggest you connect RPI South and RPI North with their own site ID to FlightAware. This includes the MLAT-client for each receiver. DUMP-NET ONLY will connect to both RPI South and RPI North so you have a total view of all ADSB and MLAT data from each site.

Here are the link to the ports.
https://flightaware.com/adsb/faq#datafeed
You want to forward port 30005 (ADSB) and port 30105 (MLAT results) to your DUMP-NET ONLY box.

Lastly, please don’t forward the DUMP-NET ONLY data back to us. We don’t need another copy of the data.

[baiqi]

If I give up MLAT (in the past, I participated in only twice （max） MLAT calculations a day, while receiver in the north could bring much more data), if reporting only ADS-B data, in this case is it acceptable to report the combined data?

North router software package and performance is limited, can not be a complete deployment of a feed system.

[david.baker]

Hmm. I guess it would depend on how the system sends data to FlightAware.

ADSB data has position and timestamps. MLAT data doesn’t have position data but has timestamps.
We use the ADSB data to synchronize the clocks and not the MLAT data. So if you send ADSB data from receiver 1 and ADSB data from receiver 2 through the same site id then FA clocks synchronization will complain that the timing is bad and MLAT will be turned off.

If you just want to send us ADSB data without MLAT then you can continue to use the system how you have it now. You can turn off MLAT with piaware-config to get rid of the error messages.

[baiqi]

Thanks for your answer, I decided to keep the existing system architecture and disable MLAT calculation😀

[jonhawkes2030]

VRS is great for viewing consolidated feeds.
http://www.virtualradarserver.co.uk/
You can even see range overlays(and multiple altitudes) for each, split between ADS-B and MLAT.

You can run it on an RPI or a PC.

[baiqi]

The shocking fact is that MLAT seems to have resumed synchronization in recent days … with Remote Data

[david.baker]

If you have 1 feed sending MLATable messages then MLAT will work. You can’t mix two feeds MLATable feeds together. I assuming you only turned off one receiver’s MLAT.

[baiqi]

Delete dump1090 --mlat option can do this?

[david.baker]

PiAware-config can do this. If you edit the script file itself it will be overwritten by piaware-config
https://flightaware.com/adsb/piaware/advanced_configuration

to show all current values use the following commandline

piaware-config -showall

to edit a value use the following command format, “piaware-config setting value”

piaware-config allow-mlat no