FlightAware Discussions

Started UAT and MLAT stopped

I added a second receiver two days ago to report UAT positions. At the same time, MLAT stopped reporting. Piaware-status looks normal. Any thoughts on how this happened?

PiAware master process (piaware) is running with pid 940.
PiAware ADS-B client (faup1090) is running with pid 1060.
PiAware ADS-B UAT client (faup978) is running with pid 11672.
PiAware mlat client (fa-mlat-client) is running with pid 1054.
Local ADS-B receiver (dump1090-fa) is running with pid 431.
Local ADS-B UAT receiver (dump978-fa) is running with pid 11561.

dump1090-fa (pid 431) is listening for ES connections on port 30005.
dump978-fa (pid 11561) is listening for UAT connections on port 30978.
faup1090 is connected to the ADS-B receiver.
faup978 is connected to the ADS-B UAT receiver.
piaware is connected to FlightAware.

dump978 is producing data on localhost:30978.
dump1090 is producing data on localhost:30005.

pr

Adding the 2nd SDR made the first one unstable, probably due to voltage on the USB port.

Alternatively you have insufficient CPU resources (only likely on an RPi1 or RPi zero).

Anyhow your piaware log will show an unstable clock:

sudo journalctl -u piaware | tail -n100

This is on a laptop computer. CPU use is about 27%. Running that command shows that MLAT is not synchronized with any nearby servers. I never had this issue prior to installing a second receiver. My primary ADS-B receiver is a FlightAware Pro Stick.

Apr 21 14:38:30 q4os-desktop piaware[940]: mlat-client(1054): Receiver status: connected
Apr 21 14:38:30 q4os-desktop piaware[940]: mlat-client(1054): Server status: not synchronized with any nearby receivers

Any idea why I’m not getting synchronized? Thanks for the reply.

sudo systemctl stop dump1090-fa piaware
sudo rtl_test

You’ll likely see lost samples.
As mentioned that usually happens due to issues with USB … be it not enough voltage for the SDR or the USB system on the computer not working correctly.
Both can be triggered by adding a 2nd USB device.

(after that test above you obviously need to restart the services to continue reception/feeding)

1 Like

Is the laptop fully dedicated to this OS? In other words, we aren’t talking about Debian or some other Linux flavor running in a virtual machine under Windows or Mac?

If it’s a VM, the USB pass through can really mess with things like this.

As a test, I pulled out the UAT receiver and now my MLAT is synchronized with 296 other receivers.

The laptop is running Q4OS (Debian). Not a VM. I was concerned maybe the clock wasn’t synchronized, but apparently that’s not the problem.

I’ll do the test @wiedehopf suggested and report back.

sudo systemctl stop dump1090-fa piaware

adminq@q4os-desktop:/etc$ sudo rtl_test
Found 2 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000978
1: Realtek, RTL2832U, SN: 00001090

Using device 0: Generic RTL2832U OEM
usb_claim_interface error -6
Failed to open rtlsdr device #0.

I moved the UAT receiver to a different USB port and rebooted. MLAT is no longer synchronized. Next I’ll use a powered USB hub and plug the UAT receiver into it to see if that fixes the problem.

Depending on your system you could try moving the receiver to a different usb host (often multiple usb ports are connected to the same host via an internal hub). On a laptop you may not have more than one available, but you can check by running lsusb -t which will give you a tree view of all the connected usb devices and which hosts and hubs they are connected through.

1 Like

I changed the UAT receiver to a different receiver. Serialized the new receiver and restarted piaware, etc. MLAT is not synchronized.

It’s an old laptop and even though the USB ports are on different sides, I suspect they may all be attached to the same hub. Here’s the result of ‘lsub -t’

adminq@q4os-desktop:~$ lsusb -t
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/10p, 480M
|__ Port 3: Dev 9, If 0, Class=Vendor Specific Class, Driver=usbfs, 480M
|__ Port 5: Dev 8, If 0, Class=Vendor Specific Class, Driver=usbfs, 480M
|__ Port 5: Dev 8, If 1, Class=Vendor Specific Class, Driver=, 480M

Yep, that machine has a single USB 2 host with both devices connected to it. It was worth a try.

1 Like

At the risk of having to completely build the station all over again :expressionless: I’m installing Q4OS on another old laptop to run lsusb -t and see if it has only one USB hub. I suspect it does because the USB ports are on the side and back, but right up again the corner.

Having only a single USB hub in a computer is fairly normal and usually not an issue.
There could be either a voltage issue or an issue with the driver / hardware.

Thus it’s not a bad idea to check if another laptop will work.

Well yeah specify the SDR then.

sudo rtl_test -d 00001090

But likely it’s just gonna show lost samples and not really help you beyond that.

Just to reinforce what wiedehopf says, if mlat drops out by going to “not synchronized” even when there are plenty of ADS-B aircraft around, that means that the intervals between ADS-B position messages are wrong by more than 100ppm on your receiver, which in turn means either the dongle crystal is doing something really weird (unlikely, especially since it only happens with the second dongle active) or you’re dropping a ton of samples due to USB bus problems somewhere.