I run my station on intel laptops. I had no upgrade path from DragonOS Jammy to DragonOS Resolute so I installed Resolute on another laptop and then manually moved everything over using scp. I run an Airspy Mini SDR so my software stack is
airspy_adsb → dump1090-fa → piaware 11.0
→ fr24feed
Did this change yesterday around 2:00 pm local time. Data is making it through to flightaware and flightradar24 but it is not participating in MLAT. It’s now roughly 8:00 am the next day.
Prior to the migration the station was sync’ing with a little over 300 nearby stations. I think I’ve checked everything at my end. Could the change in local IP be an issue? Any other thoughts?
Thr fa-mlat-client built and run on Jammy does not require python3-pyasyncore, whereas on Noble and Resolute it does require python3-pyasyncore. Please run this comand on Resolute to check:
Thanks for the response. I did check and python3-pyasyncore was not there so I installed it, restarted the piaware service and no difference.
Rather than continuing with a binary compiled on a different platform I decided to back up a little and compiled/installed piaware 11.1 from your custom script.
It is not only on your end, on your stats page says “Supported/Enabled”. It should say “Supported / Enabled (synchronized with xxx nearby receivers)”.
Possible reason (1): Inaccurate Receiver Location
Log into your FlightAware My ADS-B Page, click the gear icon next to your site, and check your exact coordinates, and if inaccurate, manually correct these.
Possible reason (2): Network Latency or Jitter
High network contention, low ISP bandwidth, or erratic packet latency (jitter) corrupts the precision timing needed for MLAT. Wi-Fi connections are highly prone to dropping packets or introducing delays
If possible, switch from Wi-Fi to a wired Ethernet cable connection. Avoid high-bandwidth network loads on the same local network.
Possible reason (3): Virtualization Lag (VMs / Proxmox / VirtualBox)
If you are running PiAware inside a Virtual Machine (VM), USB pass-through lag often compromises clock precision. The VM introduces microsecond variations (“clock jitter”) that ruin MLAT tracking.
Possible reason 3… there is no virtualization in play here. Possible reason 1… mlat was working on the old laptop and it sits beside the new laptop… antenna was not moved or touched… literally pulled the USB cable out of one laptop and plugged it into the other. But, I cross referenced with Google Maps and fine tuned the coordinates in the station setup.
Possible reason 2… there most certainly was some network jitter. I’ve optimized the network buffers, turned off the PCIe power saving, changed chrony to be gentle with time slewing. Enabled traditional QoS giving everything from this station priority and bound it to a node with -45 dBm signal strength. Validated UDP port 15266 reachability. Verified 0 packet loss…
very possible that it’s not getting sufficient voltage on the new laptop.
the timing is in reference to the SDR internal oscillator.
issues occur mostly because the SDR has a small buffer and there is data getting lost on USB due to the buffer being full (at least that’s my guess on why for example VMs do so badly, too much latency)
Thank you so much for nudging this in the right direction.
In this case the Airspy Mini SDR is on a powered USB hub so I was fairly confident sufficient voltage wasn’t the issue. But I checked the internal USB bus for possible power saving settings and they were enabled.
So in /etc/default/grub I changed the following line
GRUB_CMDLINE_LINUX_DEFAULT=“quiet splash”
to
GRUB_CMDLINE_LINUX_DEFAULT=“quiet splash usbcore.autosuspend=-1”
Rebooted the laptop and the MLAT sync locked in almost immediately.
My claims of victory were premature. It was up… then it was down. For a bit I was seeing 26% dropped UDP packets… found another hidden wifi powersave parameter… fixed that… not more dropped packets… worked for a while then it started complaining about clock stability. Tried a number of different ideas regarding the clock but none seem to stay stable beyond about 30 minutes.
If I restart piaware it will sync up MLAT but it won’t stay sync’d.
Thank you for that suggestion. Sample rate was set to 12 but bit packing had not been enabled. So I enabled it and the service Exec line now looks like…
Here is another suggestion that may help your situation. When I upgraded my system (recycled thin client) from Bookworm to Trixie I noticed CPU usage regularly spiking up (~ +15%) then back down to normal. I never saw this on Bookworm. System seemed to run OK, but I did not like these regular spikes. I found adding bit packing made the CPU usage stable. This pointed to some USB issue to me, but I was not in the mood to investigate and took the easy win by using bit packing.
Your problem led to me to investigate my issue a little more now and found that it may be related to the introduction of the “non-free-firmware” repository component in Debian. I had that listed in my debian.sources, but search results indicated that maybe some necessary proprietary firmware was held back or lost during the upgrade process. I noted that the blobs firmware-linux and firmware-linux-nonfree were not installed on my system.
So, I installed both blobs. Not sure if I needed one or both and it also installed Intel microcode on my AMD system, but no big deal. And it was only 22 MB in total. I removed the bit packing from my config, rebooted and now my system behaves like it did under Bookworm. No more spikes and a steady 19% of CPU in use.
Hope that helps you in your efforts. And for completeness about my setup, I also have autosuspend disabled in grub.
I see you are on Lubuntu, while the non-free-firmware fix that seems to work for me is for Debian. It has been ages since I used Lubuntu, the equivalent repo there is restricted or multiverse?? I get the feeling the issue is USB related wrt DragonOS/Lubuntu, but I have no practical experience with either. Is there a DragonOS or Lubuntu forum where you can raise the issue? Folks running the same base system as you may have better insights.
As you are using a laptop, is TLP installed on your system? From what I have read its settings override others. If the answer is yes, try disabling USB autosuspend there. I have no experience with TLP, but its config is said to be at /etc/tlp.conf or /etc/default/tlp and USB_AUTOSUSPEND=0 will disable.
No hard disk… but another Airspy mini doing AIS work… an integrated webcam, a touchpad, and a Realtek WLAN adapter.
A lot of the reading I’ve been doing is suggesting the issue is the newer Python in DragonOS Resolute (Ubuntu 26.04). On this system the Python version is 3.14.4 and the specific issue seems to be with the deprecation and removal of asyncore and it’s ‘replacement’ with pyasyncore that may be introducing some jitter of it’s own. Still working on researching that.
Did a little more checking/digging for a comparison of the USB host controllers on the two laptops involved.
This is from the ‘radio’ machine currently running DragonOS Jammy Ubuntu 22.04. On this machine things had been running quite well. Even with an SDRPlay RSPdx R2 also running on the USB lines.
If I’m understanding this correctly (and it’s entirely possible I’m not) the ‘radio2’ machine has very little chance of maintaining the timing required for MLAT while hosting 2 Airspy Mini’s on 1 USB controller.
