Problem Solution for MLAT Evaluation and PiAware Kernel 4.9

Hello everybody,

i am new and have only been feeding with ADS-B signals for a feew weeks now.

Again and again in can read here in the foum that there are problems with the receipt of MLAT data in connection with RaspberryPi and PiAware.
Also, i had appropriate problems that i wanted to solve.

Now i can say that there is no problem with kernel 4.9.24.

The following is important:

  • a good antenna
    I use a self-build Collinear antenna with 4 elements. a very good reception is important for MLAT because my received data is compared with other feeders.
    This can, of course, only work if the receiving area overlaps with other feeders.

  • an exact time on the RaspberryPi.
    Since the received MLAT data from my RaspberryPi are provided with a time stamp, before they are sent to a server, an exact time is particularly important.
    Unfortunately, the RaspberryPi has no hardware-clock, so the clock can run incorrectly within two days up to 15 minutes.
    Already makes a slight deviation of a few seconds the evaluation of MLAT useless.
    With me were MLAT data after 5 minutes after a restart of the RaspberryPi no longer evaluate.

So i thought about how i can stabilize the time.
It is possible to use plug-in boards with gps or radio-clock. this was for me however for the RaspberryPi too elaborate!
Time synchronization with time-servers seemed to me the best solution.
However, attempts with Internet-Timeservers did not produce any useful results.
The clock of the RaspberryPi was too bad and the latencies of the Internet-servers too long.

Since i use a mikrotik router, i have installed there a time-server locally. Also other routers have this function (e.g. FritzBox, etc.).
Now the RaspberryPi can get its time directly from the local network time-server. Fold immediately very reliably.
Furtheremore, very short intervals are also required for the time correction.

Therefore, i have corrected everything that has to do with a stable time on the RspberryPi.

Therefore, the following guide, which is to be understood as a possible example:

*** Fix Processor frequency on the RaspberryPi ***


sudo nano /boot/config.txt

Insert “force_turbo=1” in the last line!

*** Adress of Network internal time-server for the RaspberryPi ***


sudo nano /etc/ntp.conf

There add “server 192.168.178.1” as new timeserver and comment out all other timeservers with #.
Please replace IP 192.168.178.1 with the network IP of your own local timeserver!

In the same file, insert “maxpoll 6”, just below your timeserver ip.
With maxpoll the RaspberryPi is forced to keep very short intervals of time synchronization.

Then restart the RaspberryPi with


sudo shutdiwn -r now

With me this solution works perfectly and it is permanently transferred MLAT data.
For me depends the self-build antenna in the attic works well. The results are impressive.

sorry for my bad english…

greeting

Peter (DG9FFM)

The multilateration technique that we use doesn’t rely on the system clock at all, so doing anything to your system clock is irrelevant.
So the bulk of this post is not useful for fixing mlat problems.
(Of course, having an accurate system clock isn’t a bad thing…)
I would note that introducing an intermediate timeserver that’s still using the same source data isn’t going to improve things, though - you need a better timesource e.g. a GPS-disciplined clock.

What is your Pi hardware? The USB-related mlat timing problems have only been reported on Pi 2s with the newer kernel.

Hello,

i use raspberrpi 2b for piaware and after the settings I wrote in my last post, it works well.

A lokal timeserver is very interessting, because you have very low latencies for each time-poll, about 0.5ms.

The lokal timeserver uses itself an internet-timeserver. But the hardware-clock of the mikrotik-router is very stable.

Peter

I wonder if it is force turbo (which disables CPU frequency scaling IIRC) is what is helping with the pi 2 mlat issues here

Ok,
maybe…

Now i will test MLAT without force_turbo=1.

i will report the result…

So, I’ve tested times.
Force_turbo has no direct impact.

As soon as I deactivate the local timeserver, MLAT does not run stable any more.

Does it seem to have a relationship?

It seems really unlikely to be the system clock because the system clock is not used for mlat. Maybe a secondary effect of running ntp, but I can’t think what.