I got a message a few days ago from Flight Aware that they were no longer using my MLAT Data due to the location being incorrect or timing issues with the RaspBerry. I rebooted my RaspBerry and the message almost immediately went away so obviously I was having an issue with timing (I know my GPS is seat dead on to the last digit).
I am currently running the RaspBerry Pi 3 with the FlightAware ProStick
I have 2 basic questions:
1.) How often do you reset your RaspBerry?
2.) Is there any RaspBerry software that we can install that preform automatic reboots at a predetermined time?
Piaware with a Pro Stick USB doesn’t use GPS for timing. It uses a timer within the dongle and external ADS-B messages to calibrate the timings.
I got this message when my RPI3 overheated. I added a case with a fan and the temp is under control and the timing errors go away. Does the problem occur at times when the RPI could be hot? My RPI3s seems much more susceptible to heat than my RPI2.
You can use a crontab entry to reboot it on a regular basis.
Something like ths
15 03 * * Mon,Wed,Fri /sbin/reboot
Your system has an issue. Sometimes it’s a simple issue and other times it’s hard to figure out. Do you have the radio connected via a USB hub or an active repeater cable?
I know it does not use the GPS, I was talking about having the accurate GPS settings of the site setup with Flight aware. I cannot remember the exact message that I received but it was very similar to:
Flight-aware has stopped using your station for MLAT data due to either incorrect GPS location or system loading the memory.
The unit was not over heated and I rebooted and the problem has not returned since. I have been rebooting it every 3 days or so and the issues have not returned. The unit is in an air conditioned environment and stays well within temperature limits.
Thanks for your input, I will setup a crontab entry, however, I do not understand the 15 03. What I would like to have it do is to reboot at 0700 UTZ as my RaspBerry is operating on a UTZ Time. I do not use the computer for anything else, so keeping it that way is fine.
I rarely ever reboot the pi. I do get that message sometimes, maybe once or twice a month. Usually doesn’t last long, maybe 15-20 minutes and it will go away. I am using 3 pi2’s, haven’t pulled the trigger on the pi3 yet.
The CPU scales back when it gets hot. This can cause MLAT to think that the CPU is overloaded and therefore not stable. I had this issue on RPI3s that get highly utilitised, like when an Airspy or dump978.
15 03 means at 03:15. sudo crontab -l to show th crontab. -e to edit it.
How do you know the CPU wasn’t hot or overloaded? Did you look at the temp. Mine started having issues at 65C, I think(it has been a while).
If that was the case, simply rebooting the unit would not have fixed the issue. I rebooted it and it has not had a problem since. I would be more inclined to believe that it is memory leaks in the PiAware or operating system of the PiAware. The unit is not over heating.
Rebooting worked for me before I added the fan.
If it only occurred once then I wouldn’t worry about it. If it happens often then check the logs.
/tmp/piaware.out or /var/log/piaware.log
/var/log/messages
/var/log/dump1090.log
Version 3 is due out this month.
I have been running it in DEV on my devices for a few months.
If it is a software issue, then version 3 may help.
When MLAT goes TU on my setups, I usually get the message, “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.”
On the FA LOG the is a message that says “Server status: clock unstable”.
This anomaly appears to be associated with a faulty or over heating Pro-Stick.
My Pro-Sticks’ orange plastic housings have been replaced by aluminum ones to help reduce noise interference and dissipate heat. I notice that they can get quite warm (sometimes hot) to the touch.
I’m beginning to believe that the timing problem is not with the Pi’s but instead with a particular Pro-Stick. Could be wrong.
I rebooted my RPi3 + Prostick + Joe’s adsb-receiver software yesterday after 53 days, for a cable tidy up.
It’s located indoors in the UK so temperature is never an issue
System is quite busy 3,500 aircraft / 1,200,000 positions per day.
I ran Airspy for a while and got that MLAT message from FA occasionally. Resolved by setting " -w 3 " which freed up a processor and stopped the FA MLAT message.
Mlat timing errors, assuming you have your position correct, are entirely about samples being dropped.
There are many possible causes. Hardware that is close to the edge of the specs, noise on the USB bus, CPU load meaning some USB data is dropped, contention for USB bandwidth from other devices, CPU load meaning the demodulator can’t keep up with the sample stream, the general flakiness of the RTL2832 chip. Take your pick. It’s fairly normal for most systems to occasionally hit one of these issues, but they usually fix themselves.
Things that it is not are: overheating itself (though that can trigger other causes); anything to do with system clock accuracy.
Rebooting resets the piaware connection so the mlat server starts again in terms of working out the receiver clock quality. So if you have a borderline clock it might ‘work’ for a while before the server gives up on you again. But if the underlying problem is still there then you are contributing bad data.
“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.”
Correct. I’d add that the decimation option helps keeping the CPU usage very low without sacrificing a lot of accuracy: Try -d 2
In the latest version of the decoder (1.17) you can use -n switch to force the native sample rate which might be useful with the Airspy Mini. You can of course combine it with -d 2, if required.
When I swapped the suspect Pro-Stick to another one of my Pi3’s, FA started reporting the same anomaly condition on the statistic page for the MAC address for that particular Pi3. Previously, that Pi3 had no issues.
I don’t know what exactly is causing the problem, but I’m pretty certain that something funky is going on with the Pro-Stick.
During my height upgrade I found that my Lightning Detector caused Pro-Stick to shut down… Took it out and works perfectly after a reboot, plug it back in and it failed within a couple of minutes.
That would not have been my first choice… My only changes were cabling and lightning arrestor. I took the arrestor out and everything worked great (After a reboot). Take it out just for a test.
