Hello friends:
Sometimes i can read this in my stats flightaware page:
Anomaly report for PiAware feeder with a MAC address of bb:48:bb:c8:b4:6d:
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.
I am running piaware under Raspbian.
My raspberry is used also like Wifi Access Point (using hostapd + IP forward and DNS Masq).
I have found that this problem with MLAT happens when some device is using the raspberry like Access Point.
When i am not at home this Mlat problem normally doesn’t occur.
mlat synchronization relies on receiving every sample from the dongle and not dropping data.
The dongles do not have a great USB implementation and they can drop data under many conditions. If the USB bus is used by other things e.g. a wifi dongle or the built-in ethernet (which is internally a USB device), or if the Pi’s CPU is unusually busy, or if there is noise on the USB bus causing errors, then samples can be dropped which breaks mlat synchronization.
I’m seeing exactly the same problem with a RPi3 using a Flightaware Pro stick and filter which was upgraded to Piaware 3 over the weekend.
I don’t think it’s a CPU limitation though as the box is idling at around 20% CPU utilisation and only hitting a peak of about 50% when I’m connecting via VNC and viewing the local page.
I’ll try switching to ethernet rather than wifi but I am slightly concerned that this was working perfectly with PiAware 2 with exactly the same physical setup.
How did you change the dump1090 veersion? I am currently running the stock setup with an RTL-SDR stick and I just got a notification even though when I remote in I am only using about 40 percent cpu.
