Mlat Timing Issues on new PiAware?

FlightAware ADS-B Flight Tracking
1

First post, brand new stock PiAware setup that’s been running for 12 hours and I’m seeing the following error message:

Anomaly report for PiAware feeder with a MAC address of xxx:
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’m seeing this in the logs:

[2015-10-10 10:18 PDT] mlat(2398): Receiver status: connected
[2015-10-10 10:18 PDT] mlat(2398): Server status: clock unstable
[2015-10-10 10:18 PDT] mlat(2398): Receiver: 10.7 msg/s received 0.2kB/s from receiver
[2015-10-10 10:18 PDT] mlat(2398): Server: 0.0 kB/s from server 0.0kB/s TCP to server 0.1kB/s UDP to server
[2015-10-10 10:18 PDT] mlat(2398): Results: 21.3 positions/minute
[2015-10-10 10:18 PDT] mlat(2398): Aircraft: 4 of 4 Mode S, 1 of 1 ADS-B used

Site location should be fine, CPU usage is low, and Mlat was working earlier. What’s causing this issue and how do I debug?

2

I’m receiving this as well now too. How did you fix?

Thanks,
Erik

3

Same on my side - I’ve changed recently from PI B+ to PI 2 and to my surprise today I received anomalies notification. It started showing when receiver has picked up more than 300 msgs/s. Any idea on that?

4

It can be caused by:

  • cpu overloading
  • an incorrectly specified receiver position
  • a bad USB cable
  • temperature variations
  • a combination of hardware that, taken together, occasionally drops USB data

Often it is just hardware variability (the dongles aren’t great) so it is out of your control.

5

Don’t know if it is pertinent, but I had similar clock error notifications from Planeplotter recently. I did not check the RPi logs at the time. The cause appeared to be a significant DOS attack at the time. Thruput degradation was enough to be remarked on by XYL/DW

6

According to the author of Mlat client:


Unsupported receivers

The FlightRadar24 radarcape-based receiver. This produces a deliberately crippled timestamp in its output, making it useless for multilateration. If you have one of these, you should ask FR24 to fix this.

See https://github.com/mutability/mlat-client#unsupported-receivers

Could FlightRadar24 folks please fix this? Or is it inconsequential?

7

That would be me!

Could FlightRadar24 folks please fix this? Or is it inconsequential?

You might want to try asking on the FR24 forums. I always assumed it was a deliberate decision by FR24 to try to keep the data to themselves.

8

Just curious, is the the FR24 branded radarcapes or the ones sold shop.jetvision.de for lots of real money.

If it’s the former - then it’s owned by FR24 and part of the agreement for hosting it is that you wont use it to feed to anyone else.