MLAT Issues: Clock Unstable

mlat-client(25076): Server status: clock unstable

Is the error I am getting read into other’s issues but I plugged my Pro Stick Plus into the USB directly on the RaspberryPi2 any way to fix this issue?

Been troubleshooting today so I’ve had more data then I ever have. Still think it is unstable though.

Could be the USB being unstable due to the stick not getting enough voltage.
(Try a different USB port, better power supply)

You have probably checked on your status page if the elevation above ground is correctly set and the gps coordinates are correct?

Apart from that i don’t know.

But your stats also show that your receiver has received some mlat results so it’s somewhat working i guess?

Yeah I was playing with it today to see if that might be it we will see if it holds up if you look at my history it’s slim to none.

Also, back down again now.

So did you try another power supply / different usb port?

Also you can run rtl_test to see if you are dropping samples.

sudo service dump1090-fa stop
rtl_test -s 2400000

On startup a few lost samples should be no problem but over the next 10 minutes there should be no errors displayed.

Also kernel 4.9 was apparently having problems with USB on the Pi2
Not sure which image you are running, maybe just try a current one or do a

sudo rpi-update

Note that this can cause issues too and you should be willing to reimage if necessary. (hopefully not though)

1 Like

Here’s output of my rtl_test. Is this normal? Ran it for about 10 minutes. The first two messages came up shortly after starting the command, and then the next two appeared some minutes later (32 and 24 bytes lost…).

pi@raspberry:~ $ rtl_test -s 2400000
Found 1 device(s):
  0:  Realtek, RTL2832U, SN: 00001000

Using device 0: Generic RTL2832U
Detached kernel driver
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6 
[R82XX] PLL not locked!
Sampling at 2400000 S/s.

Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.

Reading samples in async mode...
Allocating 15 zero-copy buffers
lost at least 3003775 bytes
lost at least 2583706 bytes
lost at least 32 bytes
lost at least 24 bytes
^CSignal caught, exiting!

User cancel, exiting...
Samples per million lost (minimum): 1
Reattached kernel driver

Basically each “lost at least X bytes” will correspond to losing mlat sync temporarily. It will then take perhaps 30-60 seconds to recover sync. If that’s happening more frequently than perhaps once every 5 minutes then the server will treat your receiver as unstable and stop using data from it until it is more predictably stable.

Twice in 10 minutes is probably OK (hard to say without more data whether it’s really 1/5 mins or just an unlucky burst). Usually if you have USB problems then it will be really obvious, continually dropping samples.

1 Like