Required packages for running piaware, and more about mlats

[wiedehopf]

@abcd567

I cant add a non-connected USB device or change the type of USB.

Maybe you need to shut down the VirtualBox machine to change that setting?

[evangelyul]

FWIW I tried in the past both setup with success.
however the OS that worked for me - in the Virtualbox VM - were debian 9, lubuntu 16, xubuntu 16. the Debian was with and without GUI.
either via direct connection (to the Windows PC) or via RPi and Modesmixer.(1)

(1) modesmixer running in VM, grabbed data from RPi 30005.

[wiedehopf]

@evangelyul

either via direct connection (to the Windows PC)

So you didn’t pass through the USB device but ran dump1090 natively under windows?

That’s different from running dump1090-fa in the VM.

Grabbing the data from another computer works, that is known.
The discussion was about running dump1090 that reads the USB device, inside the VM.

[evangelyul]

@wiedehopf

So you didn’t pass through the USB devic

negativo ! nooelec/v3 connected to PC running the VM under win7, then via VM’s USB 2.0 driver to the VM. I think once through USB hub that shows in the list of USB VM devices, but always selected the RT28xx.

[curtko]

@abcd567

The settings dialogue only lists the USB devices currently plugged into the Windows Desktop, and I can select any from the list. I cant add a non-connected USB device or change the type of USB.

In order to switch to USB 2.0 in VirtualBox, first you have to install the VB Extension Pack: https://download.virtualbox.org/virtualbox/6.0.4/Oracle_VM_VirtualBox_Extension_Pack-6.0.4.vbox-extpack. Then you can shutdown the VM and under Settings->USB (for the VM) you change to USB 2.0 and then restart the VM.

[curtko]

@obj

I didn’t dig into it much at the time but I think it was more of a problem with the VM implementation rather than a performance issue. Some sort of bad interaction between the VM’s USB passthrough and the dongle’s not very great device-side USB implementation.

I strongly suspect this to be the case. When running piaware on Ubuntu in a VM on Fusion on my circa 2015 MacBook Pro, I am seeing mlats. But when I run it in a VM on VirtualBox on my Dell laptop (decent, but not quite as powerful as my MacBook), I don’t see any mlats. I think VB is vastly inferior compared to Fusion. I may be biased though as I work at VMware ;-).

[curtko]

$ sudo systemctl status piaware -l
● piaware.service - FlightAware ADS-B uploader
Loaded: loaded (/lib/systemd/system/piaware.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2019-03-03 21:23:42 UTC; 26min ago
Docs: PiAware - ADS-B and MLAT Receiver - FlightAware
Main PID: 861 (piaware)
Tasks: 4 (limit: 1110)
CGroup: /system.slice/piaware.service
├─ 861 /usr/bin/piaware -p /run/piaware/piaware.pid -plainlog -statusfile /run/piaware/status.json
├─ 994 /usr/lib/piaware/helpers/fa-mlat-client --input-connect localhost:30005 --input-type dump1090 --results beast,connect,localhost:30104 --results beast,listen,301
└─1001 /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --stdout --lat XXX --lon YYY

Mar 03 21:29:18 cpklinux piaware[861]: 441 msgs recv’d from dump1090-fa (394 in last 5m); 441 msgs sent to FlightAware
Mar 03 21:34:18 cpklinux piaware[861]: 764 msgs recv’d from dump1090-fa (323 in last 5m); 764 msgs sent to FlightAware
Mar 03 21:38:48 cpklinux piaware[861]: mlat-client(994): Receiver status: connected
Mar 03 21:38:48 cpklinux piaware[861]: mlat-client(994): Server status: not synchronized with any nearby receivers
Mar 03 21:38:48 cpklinux piaware[861]: mlat-client(994): Receiver: 48.5 msg/s received 14.7 msg/s processed (30%)
Mar 03 21:38:48 cpklinux piaware[861]: mlat-client(994): Server: 0.0 kB/s from server 0.0kB/s TCP to server 0.2kB/s UDP to server
Mar 03 21:38:48 cpklinux piaware[861]: mlat-client(994): Aircraft: 6 of 12 Mode S, 6 of 6 ADS-B used
Mar 03 21:39:18 cpklinux piaware[861]: 1210 msgs recv’d from dump1090-fa (446 in last 5m); 1210 msgs sent to FlightAware
Mar 03 21:44:18 cpklinux piaware[861]: 1639 msgs recv’d from dump1090-fa (429 in last 5m); 1639 msgs sent to FlightAware
Mar 03 21:49:18 cpklinux piaware[861]: 2045 msgs recv’d from dump1090-fa (406 in last 5m); 2045 msgs sent to FlightAware
+++
Mar 03 17:15:08 cpklinux piaware[922]: mlat-client(1059): Receiver status: connected
Mar 03 17:15:08 cpklinux piaware[922]: mlat-client(1059): Server status: not synchronized with any nearby receivers
Mar 03 17:30:08 cpklinux piaware[922]: mlat-client(1059): Receiver status: connected
Mar 03 17:30:08 cpklinux piaware[922]: mlat-client(1059): Server status: not synchronized with any nearby receivers
Mar 03 17:45:09 cpklinux piaware[922]: mlat-client(1059): Receiver status: connected
Mar 03 17:45:09 cpklinux piaware[922]: mlat-client(1059): Server status: not synchronized with any nearby receivers
Mar 03 18:00:09 cpklinux piaware[922]: mlat-client(1059): Receiver status: connected
Mar 03 18:00:09 cpklinux piaware[922]: mlat-client(1059): Server status: not synchronized with any nearby receivers
Mar 03 18:15:09 cpklinux piaware[922]: mlat-client(1059): Receiver status: connected
Mar 03 18:15:09 cpklinux piaware[922]: mlat-client(1059): Server status: not synchronized with any nearby receivers
Mar 03 21:38:48 cpklinux piaware[861]: mlat-client(994): Receiver status: connected
Mar 03 21:38:48 cpklinux piaware[861]: mlat-client(994): Server status: not synchronized with any nearby receivers

[evangelyul]

there must be something wrong with your hardware setup.
very low numbers for 6 aircraft.
user ‘ckuethe’ is in sync with 266 receivers only 2 nm far from your station.

see here the response for 3 aircraft and ~ 30 mlat stations in sync
~ 100K in last 5min at my setup.

[abcd567]

Today’s 2nd Experiment

INSTALLED

• On Windows Desktop in VM, installed 2018-11-26-rpd-x86-stretch.iso downloaded from Raspberry Pi Desktop for PC and Mac – Raspberry Pi

• Installed dump1090-fa and Piaware using exactly same commands as used for Ubuntu Bionic 18.04 (see this post for details).

.

RESULT:

No MLAT

.

.

.

1 of 2

pi@raspberry:~ $ sudo systemctl status piaware -l 

● piaware.service - FlightAware ADS-B uploader
   Loaded: loaded (/lib/systemd/system/piaware.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2019-03-03 18:15:41 EST; 20min ago
     Docs: https://flightaware.com/adsb/piaware/
 Main PID: 2761 (piaware)
    Tasks: 4 (limit: 4915)
   CGroup: /system.slice/piaware.service
           ├─2761 /usr/bin/piaware -p /run/piaware/piaware.pid -plainlog -statusfile /run/piaware/status.json
           ├─2776 /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --stdout --lat 43.5xxx --lon -79.6xxx
           └─2779 /usr/lib/piaware/helpers/fa-mlat-client --input-connect localhost:30005 --input-type dump1090 --results beast,connec

Mar 03 18:16:16 raspberry piaware[2761]: 62 msgs recv'd from dump1090-fa; 62 msgs sent to FlightAware
Mar 03 18:21:16 raspberry piaware[2761]: 682 msgs recv'd from dump1090-fa (620 in last 5m); 682 msgs sent to FlightAware
Mar 03 18:26:16 raspberry piaware[2761]: 1168 msgs recv'd from dump1090-fa (486 in last 5m); 1168 msgs sent to FlightAware
Mar 03 18:30:47 raspberry piaware[2761]: mlat-client(2779): Receiver status: connected
Mar 03 18:30:47 raspberry piaware[2761]: mlat-client(2779): Server status:   clock unstable
Mar 03 18:30:47 raspberry piaware[2761]: mlat-client(2779): Receiver:   92.5 msg/s received       25.1 msg/s processed (27%)
Mar 03 18:30:47 raspberry piaware[2761]: mlat-client(2779): Server:      0.0 kB/s from server    0.0kB/s TCP to server     0.3kB/s UDP
Mar 03 18:30:47 raspberry piaware[2761]: mlat-client(2779): Aircraft: 2 of 7 Mode S, 11 of 11 ADS-B used
Mar 03 18:31:16 raspberry piaware[2761]: 1655 msgs recv'd from dump1090-fa (487 in last 5m); 1655 msgs sent to FlightAware
Mar 03 18:36:16 raspberry piaware[2761]: 2372 msgs recv'd from dump1090-fa (717 in last 5m); 2372 msgs sent to FlightAware

.

2 of 2

pi@raspberry:~ $ journalctl -u piaware | grep 'Receiver status\|Server status' 

Mar 03 18:30:47 raspberry piaware[2761]: mlat-client(2779): Receiver status: connected
Mar 03 18:30:47 raspberry piaware[2761]: mlat-client(2779): Server status:   clock unstable

[abcd567]

@curtko

In order to switch to USB 2.0 in VirtualBox, first you have to install the VB Extension Pack:

Thank you.
Will install the extension pack.

[curtko]

@wiedehopf

My bet is the passthrough is not working properly.

You were right. The solution was a bit complicated (involved regedit). Here was the solution: SOLVED: Failed to access the USB subsystem on Windows 7 host - virtualbox.org
This was on my friend’s HP laptop which has Windows 10 with an AMD CPU.

[abcd567]

@wiedehopf

Can you change that to USB 2.0?

.

@curtko

In order to switch to USB 2.0 in VirtualBox, first you have to install the VB Extension Pack:

.

OK, installed VB Extension Pack, then switched to USB 2.0:
STILL NO MLAT

UBUNTU BIONIC IN VM ON WINDOWS

Screenshot 1 of 5: VM USB selected to 2.0

.

Screenshot 2 of 5: VM SkyView, no mlat

.

Screenshot 3 of 5: FA Stats page, mlat ok, but number of stations synchronized is not there (zero???).

abcd@ubuntu:~$ journalctl -u piaware | grep 'Receiver status\|Server status'

Mar 03 14:06:18 ubuntu piaware[692]: mlat-client(815): Receiver status: connected
Mar 03 14:06:18 ubuntu piaware[692]: mlat-client(815): Server status:   clock unstable
Mar 03 14:21:18 ubuntu piaware[692]: mlat-client(815): Receiver status: connected
Mar 03 14:21:18 ubuntu piaware[692]: mlat-client(815): Server status:   clock unstable
Mar 03 14:36:18 ubuntu piaware[692]: mlat-client(815): Receiver status: connected
Mar 03 14:36:19 ubuntu piaware[692]: mlat-client(815): Server status:   clock unstable
Mar 03 14:51:19 ubuntu piaware[692]: mlat-client(815): Receiver status: connected
Mar 03 14:51:19 ubuntu piaware[692]: mlat-client(815): Server status:   clock unstable
Mar 03 15:06:19 ubuntu piaware[692]: mlat-client(815): Receiver status: connected
Mar 03 15:06:19 ubuntu piaware[692]: mlat-client(815): Server status:   clock unstable
Mar 03 15:21:20 ubuntu piaware[692]: mlat-client(815): Receiver status: connected
Mar 03 15:21:20 ubuntu piaware[692]: mlat-client(815): Server status:   clock unstable
Mar 03 15:59:45 ubuntu piaware[684]: mlat-client(2106): Receiver status: disconnected
Mar 03 15:59:45 ubuntu piaware[684]: mlat-client(2106): Server status:   connected
Mar 04 11:24:26 ubuntu piaware[705]: mlat-client(849): Receiver status: connected
Mar 04 11:24:26 ubuntu piaware[705]: mlat-client(849): Server status:   not synchronized with any nearby receivers
Mar 04 11:39:27 ubuntu piaware[705]: mlat-client(849): Receiver status: connected
Mar 04 11:39:27 ubuntu piaware[705]: mlat-client(849): Server status:   not synchronized with any nearby receivers
Mar 04 11:54:28 ubuntu piaware[705]: mlat-client(849): Receiver status: connected
Mar 04 11:54:28 ubuntu piaware[705]: mlat-client(849): Server status:   not synchronized with any nearby receivers
Mar 04 12:09:28 ubuntu piaware[705]: mlat-client(849): Receiver status: connected
Mar 04 12:09:28 ubuntu piaware[705]: mlat-client(849): Server status:   not synchronized with any nearby receivers

.

Raspbian Stretch on RPi

Screenshot 4 of 5: SkyView, lot of mlat (bright yellow planes)

.

Screenshot 5 of 5: FA Stats page, mlat ok, and number of stations synchronized is very large (117)

[curtko]

This is similar to what I’ve been seeing, except I have not been getting any “clock unstable” messages:

$ sudo systemctl status piaware -l

● piaware.service - FlightAware ADS-B uploader
Loaded: loaded (/lib/systemd/system/piaware.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2019-03-03 21:23:42 UTC; 20h ago
Docs: PiAware - ADS-B and MLAT Receiver - FlightAware
Main PID: 861 (piaware)
Tasks: 4 (limit: 1110)
CGroup: /system.slice/piaware.service
├─ 861 /usr/bin/piaware -p /run/piaware/piaware.pid -plainlog -statusfile /run/piaware/status.json
├─ 994 /usr/lib/piaware/helpers/fa-mlat-client --input-connect localhost:30005 --input-type dump1090 --results beast,connect,localhost:30104 --results beast,listen,301
└─1001 /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --stdout --lat XXX --lon YYY

Mar 04 17:09:21 cpklinux piaware[861]: mlat-client(994): Aircraft: 9 of 16 Mode S, 14 of 15 ADS-B used
Mar 04 17:14:18 cpklinux piaware[861]: 71771 msgs recv’d from dump1090-fa (701 in last 5m); 71771 msgs sent to FlightAware
Mar 04 17:19:18 cpklinux piaware[861]: 72656 msgs recv’d from dump1090-fa (885 in last 5m); 72656 msgs sent to FlightAware
Mar 04 17:24:18 cpklinux piaware[861]: 73426 msgs recv’d from dump1090-fa (770 in last 5m); 73426 msgs sent to FlightAware
Mar 04 17:24:21 cpklinux piaware[861]: mlat-client(994): Receiver status: connected
Mar 04 17:24:21 cpklinux piaware[861]: mlat-client(994): Server status: not synchronized with any nearby receivers
Mar 04 17:24:21 cpklinux piaware[861]: mlat-client(994): Receiver: 77.6 msg/s received 22.1 msg/s processed (28%)
Mar 04 17:24:21 cpklinux piaware[861]: mlat-client(994): Server: 0.0 kB/s from server 0.0kB/s TCP to server 0.3kB/s UDP to server
Mar 04 17:24:21 cpklinux piaware[861]: mlat-client(994): Aircraft: 5 of 11 Mode S, 13 of 14 ADS-B used
Mar 04 17:29:18 cpklinux piaware[861]: 74011 msgs recv’d from dump1090-fa (585 in last 5m); 74011 msgs sent to FlightAware

$ journalctl -u piaware | grep ‘Receiver status|Server status’

Mar 04 15:24:17 cpklinux piaware[861]: mlat-client(994): Receiver status: connected
Mar 04 15:24:17 cpklinux piaware[861]: mlat-client(994): Server status: not synchronized with any nearby receivers
Mar 04 15:39:18 cpklinux piaware[861]: mlat-client(994): Receiver status: connected
Mar 04 15:39:18 cpklinux piaware[861]: mlat-client(994): Server status: not synchronized with any nearby receivers
Mar 04 15:54:18 cpklinux piaware[861]: mlat-client(994): Receiver status: connected
Mar 04 15:54:18 cpklinux piaware[861]: mlat-client(994): Server status: not synchronized with any nearby receivers
Mar 04 16:09:19 cpklinux piaware[861]: mlat-client(994): Receiver status: connected
Mar 04 16:09:19 cpklinux piaware[861]: mlat-client(994): Server status: not synchronized with any nearby receivers
Mar 04 16:24:20 cpklinux piaware[861]: mlat-client(994): Receiver status: connected
Mar 04 16:24:20 cpklinux piaware[861]: mlat-client(994): Server status: not synchronized with any nearby receivers
Mar 04 16:39:20 cpklinux piaware[861]: mlat-client(994): Receiver status: connected
Mar 04 16:39:20 cpklinux piaware[861]: mlat-client(994): Server status: not synchronized with any nearby receivers
Mar 04 16:54:20 cpklinux piaware[861]: mlat-client(994): Receiver status: connected
Mar 04 16:54:20 cpklinux piaware[861]: mlat-client(994): Server status: not synchronized with any nearby receivers
Mar 04 17:09:21 cpklinux piaware[861]: mlat-client(994): Receiver status: connected
Mar 04 17:09:21 cpklinux piaware[861]: mlat-client(994): Server status: not synchronized with any nearby receivers
Mar 04 17:24:21 cpklinux piaware[861]: mlat-client(994): Receiver status: connected
Mar 04 17:24:21 cpklinux piaware[861]: mlat-client(994): Server status: not synchronized with any nearby receivers

[evangelyul]

here is my xubuntu VM currently on-line.
Modesmixer data from a v3 dongle on another PC running Win7 and Modesdeco2.
VM modesmixer string:

/home/xub/modesmixer2 \
--google-key xxxxxxxxxxxxxxxxxxxxxxxxxxx \
--inConnect 192.168.1.44:33335 \ 
--inServer 30104 \
--outServer beast:30005 \
--outConnect beast:localhost:30105 \
--location 37.9:23.7 &

[obj]

If you’re dropping a small amount of USB data then you’ll get “clock unstable” - the mlat server is managing to match up beacon messages with other receivers, but the results are highly variable.

If you’re dropping a lot of USB data then the mlat server won’t even manage to match up the beacon messages because the interval between each pair is too far out of spec; the mlat server only accepts / compensates for up to ~100ppm error. If this happens you just get no synchronization at all.

[obj]

@evangelyul

here is my xubuntu VM currently on-line.
Modesmixer data from a v3 dongle on another PC running Win7 and Modesdeco2.

This is a different setup, because your decoder isn’t running in a VM, and it’s the decoder that is sensitive to USB problems.

[evangelyul]

@obj

the decoder that is sensitive to USB problems.

thanks Oliver, I appreciate that, will try another setup with the main PC (athlon) and nooelec dongle, see how it goes.

[abcd567]

Yesterday (March 03) logs were telling “clock unstable”.

Today (March 04) logs do not say “clock unstable”. logs say “not synchronized with any nearby receivers”.

Now if today the clock is NOT unstable, why still it is not synchronized with any of nearby receivers?

abcd@ubuntu:~$ journalctl -u piaware | grep 'Receiver status\|Server status' 

Mar 03 14:06:18 ubuntu piaware[692]: mlat-client(815): Receiver status: connected
Mar 03 14:06:18 ubuntu piaware[692]: mlat-client(815): Server status:   clock unstable
Mar 03 14:21:18 ubuntu piaware[692]: mlat-client(815): Receiver status: connected
Mar 03 14:21:18 ubuntu piaware[692]: mlat-client(815): Server status:   clock unstable
Mar 03 14:36:18 ubuntu piaware[692]: mlat-client(815): Receiver status: connected
Mar 03 14:36:19 ubuntu piaware[692]: mlat-client(815): Server status:   clock unstable
Mar 03 14:51:19 ubuntu piaware[692]: mlat-client(815): Receiver status: connected
Mar 03 14:51:19 ubuntu piaware[692]: mlat-client(815): Server status:   clock unstable
Mar 03 15:06:19 ubuntu piaware[692]: mlat-client(815): Receiver status: connected
Mar 03 15:06:19 ubuntu piaware[692]: mlat-client(815): Server status:   clock unstable
Mar 03 15:21:20 ubuntu piaware[692]: mlat-client(815): Receiver status: connected
Mar 03 15:21:20 ubuntu piaware[692]: mlat-client(815): Server status:   clock unstable
Mar 03 15:59:45 ubuntu piaware[684]: mlat-client(2106): Receiver status: disconnected
Mar 03 15:59:45 ubuntu piaware[684]: mlat-client(2106): Server status:   connected

Mar 04 11:24:26 ubuntu piaware[705]: mlat-client(849): Receiver status: connected
Mar 04 11:24:26 ubuntu piaware[705]: mlat-client(849): Server status:   not synchronized with any nearby receivers
Mar 04 11:39:27 ubuntu piaware[705]: mlat-client(849): Receiver status: connected
Mar 04 11:39:27 ubuntu piaware[705]: mlat-client(849): Server status:   not synchronized with any nearby receivers
Mar 04 11:54:28 ubuntu piaware[705]: mlat-client(849): Receiver status: connected
Mar 04 11:54:28 ubuntu piaware[705]: mlat-client(849): Server status:   not synchronized with any nearby receivers
Mar 04 12:09:28 ubuntu piaware[705]: mlat-client(849): Receiver status: connected
Mar 04 12:09:28 ubuntu piaware[705]: mlat-client(849): Server status:   not synchronized with any nearby receivers
Mar 04 12:24:28 ubuntu piaware[705]: mlat-client(849): Receiver status: connected
Mar 04 12:24:28 ubuntu piaware[705]: mlat-client(849): Server status:   not synchronized with any nearby receivers
Mar 04 12:39:29 ubuntu piaware[705]: mlat-client(849): Receiver status: connected
Mar 04 12:39:29 ubuntu piaware[705]: mlat-client(849): Server status:   not synchronized with any nearby receivers
Mar 04 12:54:30 ubuntu piaware[705]: mlat-client(849): Receiver status: connected
Mar 04 12:54:30 ubuntu piaware[705]: mlat-client(849): Server status:   not synchronized with any nearby receivers
Mar 04 13:09:30 ubuntu piaware[705]: mlat-client(849): Receiver status: connected
Mar 04 13:09:30 ubuntu piaware[705]: mlat-client(849): Server status:   not synchronized with any nearby receivers

[curtko]

@obj

If you’re dropping a small amount of USB data then you’ll get “clock unstable” - the mlat server is managing to match up beacon messages with other receivers, but the results are highly variable.

If you’re dropping a lot of USB data then the mlat server won’t even manage to match up the beacon messages because the interval between each pair is too far out of spec; the mlat server only accepts / compensates for up to ~100ppm error. If this happens you just get no synchronization at all.

Thanks for the info. @abcd567 – you could be having the same issue. It could be because of the same reason I’m not seeing any “clock unstable” messages.

[abcd567]

@curtko
Oh, It seems I missed @obj 's post. Thanks for quoting it, and thanks to Oliver for the info. It makes things clear.