mlat not working with piaware

[hugalafutro]

Hi,

I've noticed fligthaware reports 0 mlat aircraft, on their web it says
This feeder is not being used for multilateration because its timing information appears to be unreliable. This can be caused by the site location being incorrect, or because your Pi is running out of free CPU.

in the log it indeed says:

[piaware] 2024/04/19 11:01:40 mlat-client(166): Receiver status: connected
[piaware] 2024/04/19 11:01:40 mlat-client(166): Server status:   clock unstable
[piaware] 2024/04/19 11:01:40 mlat-client(166): Receiver:  130.4 msg/s received       22.4 msg/s processed (17%)
[piaware] 2024/04/19 11:01:40 mlat-client(166): Server:      0.0 kB/s from server    0.0kB/s TCP to server     0.3kB/s UDP to server
[piaware] 2024/04/19 11:01:40 mlat-client(166): Aircraft: 7 of 8 Mode S, 9 of 9 ADS-B used

but for other feeder seems to work ok:

[mlat-client] Fri Apr 19 11:31:43 2024 Receiver status: connected
[mlat-client] Fri Apr 19 11:31:43 2024 Server status:   ready
[mlat-client] Fri Apr 19 11:31:43 2024 Receiver:  231.7 msg/s received       15.4 msg/s processed (7%)
[mlat-client] Fri Apr 19 11:31:43 2024 Server:      0.0 kB/s from server    0.2kB/s TCP to server     0.0kB/s UDP to server
[mlat-client] Fri Apr 19 11:31:43 2024 Results:  0.7 positions/minute
[mlat-client] Fri Apr 19 11:31:43 2024 Aircraft: 1 of 3 Mode S, 5 of 8 ADS-B used
[pw-feeder] 2024-04-19T11:35:57+01:00 INF atc.plane.watch reported connection status ADSB=healthy MLAT=healthy
[pw-feeder] 2024-04-19T11:36:35+01:00 INF connection statistics bytesRxLocal=24460645 bytesRxRemote=0 bytesTxLocal=0 bytesTxRemote=24460645 proto=BEAST
[pw-feeder] 2024-04-19T11:36:35+01:00 INF connection statistics bytesRxLocal=1552404 bytesRxRemote=19099 bytesTxLocal=19099 bytesTxRemote=1552404 proto=MLAT

I've checked documentation and everything is set up accordingly, the host (vm with more power than pi Linux docker-vm 6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11) x86_64 GNU/Linux) time is synced with ntp:

Local time: Fri 2024-04-19 11:39:00 BST
Universal time: Fri 2024-04-19 10:39:00 UTC
RTC time: Fri 2024-04-19 10:39:00
Time zone: Europe/London (BST, +0100)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

Is there anything I can do about this?

[hugalafutro]

started working after I updated all containers today

[kx1t]

VMs are known to cause instabilities in the timing for MLAT. Also, the FlightAware MLAT service is known to be very finicky about timing (while other MLAT services appear to complain less about this).

So this is an unfortunate side effect of using VMs and not something we can fix from our side.

[hugalafutro]

I see, thanks for letting me know (I noticed later that it was off again, but didn't want to reopen this as I suspected the issue might be due to the multiple emulation layers as I faced somewhat similar issue while trying to use google coral tpu in docker inside vm)