PIAWARE 3 Issue

FlightAware ADS-B Flight Tracking
1

Hi,
Upgraded to PIAWARE 3 my Raspberry PI 2 board last week. All working well until today when I see some log errors

“•Anomaly report for PiAware feeder with a MAC address of b8:27:eb:11:6d:11:
1.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 have restarted PIAWARE 3 and the error reoccurs after a short time. It is not stopping the data been sent to FA. PIAWARE3 is the only program loaded and running on the PI2 board.

Any ideas what causing this error, is the CPU too loaded?

Regs

Liam

2

have you checked if your location is right and in right format? you can see your ram and cpu by enter this command :
free -h -s 1
the nummer 1 make a refresh every 1 second change at your wish

Sent from my SM-N910F using Tapatalk

3

Receiver latitude & longitude are set in which file of Piaware 3?
The file /boot/piaware-config.txt does not have lat/lon setting.

4

They are in /usr/share/dump1090-fa/html/config.js

(hint: do NOT turn on clocks in this file as they are broken, no longer used or supported, and will break things)

bob k6rtm

5

Thanks bob for both pieces of info (lat/lon & clocks).
Would changing lat/lon in /usr/share/dump1090-fa/html/config.js will automatically change receiver location settings on FA stats page?

6

Don’t know the answer to that one! I’d look at the startup javascript code to see who picks up what.

bob k6rtm

7

Ok,
checking the location in the config.js file. However, I am noticing more errors in the log
“mlat-client(20471): Out-of-order timestamps: 2”

Does this mean it is not a location issue but a cpu resource issue. ?

Regs

Liam

8

set your location on fa webpage, and restar fa
sudo service piaware restart

Sent from my SM-N910F using Tapatalk

9

the “out of order timestamps” is an mlat issue, nothing to do with locations – obj has commented on it in other threads.

–bob k6rtm

10

Specifically it is a new diagnostic, not a new issue (it was always happening, you just wouldn’t see it)

11

Seeing a like situation here but mine will also add second error that MLAT is no longer being used. I have reverted to the last Piaware 2 sd card. Wish now I had copied exact error. This was on my secondary low antenna Pi which I keep alive for a standby.

My primary receiver has been upgraded to a Pi3 and is running the latest Piaware image file and does not exhibit any errors. It is on a better antenna etc and sees perhaps four to five times the traffic as the pi2. Both are at the same location also.

I had been lurking on this issue because I thought it was perhaps a real hardware issue and did not want to mention until I saw someone else report.

12

I took a closer look at this and it should really be named “discontinuous timestamps” or something like that. It counts messages where the timestamp is more than 90 seconds different to the previous timestamp. This can trigger if you have low traffic and don’t receive anything for >90 seconds. So ignore it if there are low number of jumps.

13

Hi,

I have a lot of “Out-of-order timestamps” since I upraded from 3.1 to 3.5 some days ago.

Any advice ?

Thanks.
J-Luc F1JEK

14

How many is “a lot”?
What is your hardware and software setup?

15

mlat-client(1560): Out-of-order timestamps: 523
[2017-04-29 16:05 CEST] 206722 msgs recv’d from dump1090-fa (1634 in last 5m); 206721 msgs sent to FlightAware
[2017-04-29 16:05 CEST] mlat-client(1560): Warning: the timestamps provided by your receiver do not seem to be self-consistent. This can happen if you feed data from multiple receivers to a single mlat-client, which is not supported; use a separate mlat-client for each receiver.

PI2 B+, RTL-SDR.COM stick, Ubuntu 16.04.

Otherwise working very well.

J-Luc

16

What is your software setup? Do you have any other software connected to dump1090-fa?
That many bad timestamps almost certainly means that you are combining a data feed other than the rtlsdr input.

17

I have a second M-LAT client but it feeds another server and has never been a problem.

A VirtualRadar is also connected but running on a separate PC.

The Piaware installation is standard, done from the packets.

@RpiRadio:/etc/default$ cat dump1090-fa

dump1090-fa configuration

This is read by the systemd service file as an environment file,

and evaluated by some scripts as a POSIX shell fragment.

If you are using a PiAware sdcard image, this config file is regenerated

on boot based on the contents of piaware-config.txt; any changes made to this

file will be lost.

–gain -10

RECEIVER_OPTIONS=“–device-index 0 --ppm 0 --gain 49.6 --modeac --net-bo-port 30005 --forward-mlat”
DECODER_OPTIONS=“–max-range 500”
NET_OPTIONS=“–net --net-heartbeat 60 --net-ro-size 1000 --net-ro-interval 1 --net-ri-port 0 --net-ro-port 30002 --net-sbs-port 30003 --net-bi-port 30004,30104 --net-bo-port 30005”
JSON_OPTIONS=“–json-location-accuracy 1”

@RpiRadio:/etc/default$ sudo service piaware status
● piaware.service - FlightAware ADS-B uploader
Loaded: loaded (/lib/systemd/system/piaware.service; enabled; vendor preset: enabled)
Active: active (running) since ven. 2017-04-28 22:34:27 CEST; 21h ago
Docs: flightaware.com/adsb/piaware/
Main PID: 1180 (piaware)
CGroup: /system.slice/piaware.service
├─1180 /usr/bin/piaware -p /run/piaware/piaware.pid -plainlog -statusfile /run/piaware/status.json
├─1534 /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --stdout --lat 4
└─1560 /usr/lib/piaware/helpers/fa-mlat-client --input-connect localhost:30005 --input-type dump1090 –

avril 29 20:15:13 RpiRadio piaware[1180]: 280845 msgs recv’d from dump1090-fa (1248 in last 5m); 280844 msgs sent
avril 29 20:20:13 RpiRadio piaware[1180]: 282025 msgs recv’d from dump1090-fa (1180 in last 5m); 282024 msgs sent
avril 29 20:20:15 RpiRadio piaware[1180]: mlat-client(1560): Receiver status: connected
avril 29 20:20:15 RpiRadio piaware[1180]: mlat-client(1560): Server status: synchronized with 13 nearby receiver
avril 29 20:20:15 RpiRadio piaware[1180]: mlat-client(1560): Receiver: 1482.9 msg/s received 162.1 msg/s proc
avril 29 20:20:15 RpiRadio piaware[1180]: mlat-client(1560): Server: 0.1 kB/s from server 0.0kB/s TCP to s
avril 29 20:20:15 RpiRadio piaware[1180]: mlat-client(1560): Results: 25.9 positions/minute
avril 29 20:20:15 RpiRadio piaware[1180]: mlat-client(1560): Aircraft: 9 of 19 Mode S, 19 of 78 ADS-B used
avril 29 20:20:15 RpiRadio piaware[1180]: mlat-client(1560): Out-of-order timestamps: 349
avril 29 20:20:58 RpiRadio piaware[1180]: mlat-client(1560): Warning: the timestamps provided by your receiver do

18

Does this “other server” feeds-back the M-LAT results to your Pi?
If yes, to which port of your Pi this feed-back is configured to connect? To port 30104 OR 30004 or some other port?

19

No, it does not feeback, it’s the standard M-lat client from github, it feeds an external server.

Nevertheless, I am not the only one having this error… and my Mlat stats are correct.

I dont’ understand.

J-Luc

20

How are you starting the other mlat-client? What command-line options?
If you stop the other mlat-client, does the out-of-order timestamp error go away?
If you remove --forward-mlat from your dump1090 options, does the out-of-order timestamp error go away?