Thank you @caius for explanation.
I understand that time and location accuracy are good for mlat.
If I recall correctly, when in Planefinder forum someone asked why they dont allow mlat, a staff member replied that they allow mlat only for their supplied receivers which have FPGA, and since DVB-T based receivers dont have FPGA they dont allow mlat for these receivers.
The Flightradar24 also have stopped allowing mlat for DVB-T based receivers
I’ve also wondered the benefit of GPS on a stationary site.
“Independent time” sounds good until you realise that when you don’t have NTP, you don’t have MLAT and you aren’t feeding any sights.
Actually the absolute time isn’t that important for mlat as done by flight aware and others that use the same software.
The reason FR24 and planefinder don’t use rtl receivers for mlat is that their timestamps are applied to the messages when they arrive over the USB bus. That gives lower accuracy as the usb transfer can introduce jitter, so while the message is stamped to 12MHz resolution, the timestamp is not necessarily exactly the time it arrived at the receiver.
The planefinder and FR24 hardware supply the timestamps in hardware prior to the message being output to the system. That allows a GPS disciplined timestamp to be used, which means that they can be directly compared between different receivers as they all have the same reference.
The FA system doesn’t use an accurate timestamp to synchronise the receivers, instead it uses the time of arrival of messages from commonly visible ads-b aircraft, to work out the difference in timing of arrival of the mlat aircraft.
That is a very clever solution, but it does have the inherent limitation that any usb jitter is incorporated into the calculations twice - once for the synchronisation, and once the target message.
The GPS disciplined method gives visibly better results, but requires the ability to accurately tag the messages in hardware. The FA method is good enough to get an (quite close) idea the position, but the limitations are why you see the tracks wobble around somewhat.
In Linux the default memory allocation for USB xfers is 16MB. Increase the number of USB devices connected and the possibility of the default memory being insufficient increases. I have no idea if this could cause the issue you are having, but it is an easy, zero cost option to try out. I like things like that.
You can increase the memory, to say 64MB, with the following command:
sudo sh -c ‘echo 64 > /sys/module/usbcore/parameters/usbfs_memory_mb’
Check that the change took effect with this:
cat /sys/module/usbcore/parameters/usbfs_memory_mb
This change is temporary - it will not survive a reboot. If you want a permanent change you need to add an option to grub.
What about using following method?
(1) Issue following command. It may ask editor to use, select nano
crontab -e
(2) In file opened scroll down to bottom and add following line, and save file
@reboot '/usr/bin/sh -c `echo 64 > /sys/module/usbcore/parameters/usbfs_memory_mb'
LATER EDIT:
Tested above method on RPi, found above entry in crontab fails to replace 16 by 64 due to permission issue. Used following entry in crontab which overcomes permissions issue:
@reboot echo 64 | sudo tee /sys/module/usbcore/parameters/usbfs_memory_mb
Now on every reboots, cron will issue the command.
Interesting account of MLAT, but you may have missed my point.
I was just pointing out that if you need an onboard GPS to maintain time because NTP isn’t available (ie. you have no internet connection), then having GPS really won’t help your feeding stats.
I will likely try dvsvejk’s USB idea and see what happens. As far as the GPS, my only real reason for adding it was because I had one and because I could. Great reasoning I know. It is useful for time keeping but if it’s the root cause of all of this, definitely not worth it. Keep you all updated as my troubleshooting continues.
Matt
acTuaLLy 
USB jitter is not an issue, only losing data on the bus is an issue.
(which can happen rather quickly as the rtl-sdr internal buffer is small, so if there is delays in transferring the data via USB, that buffer can overrun)
A sample counter is used as free running clock which follows of course the SDR sampling frequency.
Some very disconnected writeup of how it works: mlat thoughts · wiedehopf/adsb-wiki Wiki · GitHub
You’re right, the track of an MLAT aircraft does jump around a bit. Had not noticed that before.
Yes, true, but adding a GPS dongle / GPS hat wont help as it is no better than clock in the receivers. Please see statement of Planefinder Administrator in my above post.
Speaking of all this MLAT wizardry, I noticed that Airnav/Radarbox no longer shows me feeding MLAT as it did before creating this new image a month or so ago. It was working before and as far as I can tell, all of my settings say it should work. No idea what the problem is 
Matt
For the Raspberry Pi 4, the 64-bit Raspberry Pi OS is the recommended choice. It delivers about 30–48% faster performance for CPU-heavy and memory-intensive tasks, and unlocks the full capacity of the board. However, the 32-bit version remains an option if you are running software that strictly requires 32-bit architecture.
Key Differences
When to Choose 64-bit
When to Choose 32-bit
There already exists a defined option for grub to cover this instance, so to me it is a cleaner method to institute a permanent change. An example:
GRUB_CMDLINE_LINUX_DEFAULT=“quiet usbcore.usbfs_memory_mb=64”
Thank you.
Can you please tell us in which file on Raspberry Pi OS Bookworm this grub command to be added?
To my knowledge, In standard PC installations of Debian, GRUB_CMDLINE_LINUX_DEFAULT is located in file /etc/default/grub. However on Raspberry Pi OS, this file does not exist.
Raspberry Pi uses a proprietary firmware bootloader rather than GRUB.
I do not use the Pi OS so the following answer is not from personal experience but from our trustworthy (?) friend Google/AI. Though in this case it does seem to be a sensible answer.
1. Open the file /boot/firmware/cmdline.txt in your preferred text editor
2. Append the following (in the same line):
usbcore.usbfs_memory_mb=
3. Reboot the system
4. Check if the changes are applied. The following command should print 0:
cat /sys/module/usbcore/parameters/usbfs_memory_mb
Yes this worked. Thank you.
(1) Modification, specified mb=64
(2) Checked after reboot, confirmed usbfs_memory_mb is 64
