Upgraded from 2.1-5 to 3.3-0 - MLAT timestamps

FlightAware ADS-B Flight Tracking
1

Hello
I used the “upgrade and restart PiAware” on my Flightaware Stats page to upgrade today.
I use VirtualRadar and I think I’m reaching parts that I never used to reach.
However, on restarting PiAware, the log shows:-
01/24/2017 14:16:44 Starting multilateration client: /usr/lib/piaware/helpers/fa-mlat-client --input-connect localhost:30005 --input-type dump1090 --results beast,connect,localhost:30004 --results basestation,listen,30055 --udp-transport 70.42.6.191:6820:2418384869
01/24/2017 14:16:46 mlat-client(2774): fa-mlat-client 0.2.8 starting up
01/24/2017 14:16:46 mlat-client(2774): Using UDP transport to 70.42.6.191 port 6820
01/24/2017 14:16:46 mlat-client(2774): Listening for Basestation-format results connection on port 30055
01/24/2017 14:16:47 mlat-client(2774): Input connected to localhost:30005
01/24/2017 14:16:47 mlat-client(2774): Input format changed to BEAST, 12MHz clock
01/24/2017 14:16:47 mlat-client(2774): Beast-format results connection with 127.0.0.1:30004: connection established
01/24/2017 14:16:49 piaware has successfully sent several msgs to FlightAware!
01/24/2017 14:16:49 mlat-client(2774): Accepted Basestation-format results connection from 192.168.254.104:63528
01/24/2017 14:17:09 34 msgs recv’d from dump1090; 23 msgs sent to FlightAware
01/24/2017 14:17:47 NOTICE from adept server: 27% of multilateration messages (UDP) are not reaching the server - check your network?
01/24/2017 14:18:48 NOTICE from adept server: 33% of multilateration messages (UDP) are not reaching the server - check your network?
01/24/2017 14:19:00 mlat-client(2774): 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.
01/24/2017 14:22:09 366 msgs recv’d from dump1090 (332 in last 5m); 355 msgs sent to FlightAware

It seems like the upgrade has retained the v2 Ports, but I’m concerned about the:
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.
messages.

Any comments please?

2

I guess you explicitly configured the mlat results config to something other than the default. The upgrade won’t touch your settings there.

What is your full configuration? What dump1090 are you using?

3

Plain dump1090 installed February 2016 using instructions here, I think: https://forum.planefinder.net/threads/raspberry-pi-b-rpi2-rpi3-installation-instructions-for-raspbian-dump1090-data-feeder.241/

piaware-status:
PiAware master process (piaware) is running with pid 2737.
PiAware ADS-B client (faup1090) is running with pid 2766.
PiAware mlat client (fa-mlat-client) is running with pid 2774.
Local ADS-B receiver (dump1090) is running with pid 2212.
dump1090 (pid 2212) is listening for connections on port 30005.
faup1090 is connected to the ADS-B receiver.
piaware is connected to FlightAware.
dump1090 is producing data on localhost:30005.

VirtualRadar is receiving Beast on 30005
FA MLAT on 30055
And I’ve set up Merged feed

Anything else I can send that might help please?

4

You should not feed mlat data to plain dump1090, it is not mlat-aware and will loop it back, which is what causes the complaints. Please install dump1090-mutability or dump1090-fa or disable the local loopback to port 30004.

5

Many thanks - I’ll look into that in the morning.
BTW, I also just found lots of:
2017-01-24 11:51:06.968087 !] Data upload failed with error: ‘Client not authenticated - local time on client out of limits, suggest setting up NTP locally - for help contact support@planefinder.net’

  • in the logs - so I guess that’s another side effect.
6

So I should remove:
beast,connect,localhost:30004
from my mlat-results-format
and VirtualRadar will be OK.

Thanks for your help.
Re-reading the docs, I think that I should really upgrade my Pi to Jessie and start over!

7

I do my best to support old installs but they do get a bit creaky over time…

8

Fully (and much) appreciated!

9

Just for the record. Removing:
beast,connect,localhost:30004
has removed the error messages.

10

Hi ,
where did you turn this off? This entry I did not under “dump” :open_mouth:

After the update to the latest version I have the same error see LOG:

Feb 14 14:13:07 flight145 piaware[631]: piaware version 3.3.0 is running, process ID 631
Feb 14 14:13:07 flight145 piaware[631]: your system info is: Linux flight145 4.4.38-v7+ #938 SMP Thu Dec 15 15:22:21 GMT 2016 armv7l GNU/Linux
Feb 14 14:13:09 flight145 piaware[631]: Connecting to FlightAware adept server at piaware.flightaware.com/1200
Feb 14 14:13:09 flight145 piaware[631]: Connection with adept server at piaware.flightaware.com/1200 established
Feb 14 14:13:09 flight145 piaware[631]: TLS handshake with adept server at piaware.flightaware.com/1200 completed
Feb 14 14:13:10 flight145 piaware[631]: FlightAware server certificate validated
Feb 14 14:13:10 flight145 piaware[631]: encrypted session established with FlightAware
Feb 14 14:13:10 flight145 piaware[631]: ADS-B data program ‘dump1090-mutabi’ is listening on port 30005, so far so good
Feb 14 14:13:10 flight145 piaware[631]: Starting faup1090: /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --stdout --lat **.040 --lon *.649
Feb 14 14:13:10 flight145 piaware[631]: Started faup1090 (pid 804) to connect to dump1090-mutabi
Feb 14 14:13:10 flight145 piaware[631]: adept reported location: **.04001, **.64850, 75ft AMSL
Feb 14 14:13:10 flight145 piaware[631]: logged in to FlightAware as user *
Feb 14 14:13:10 flight145 piaware[631]: my feeder ID is **********************************
Feb 14 14:13:10 flight145 piaware[631]: site statistics URL: flightaware.com/adsb/stats/user … **********
Feb 14 14:13:30 flight145 piaware[631]: piaware received a message from dump1090-mutabi!
Feb 14 14:13:30 flight145 piaware[631]: piaware has successfully sent several msgs to FlightAware!
Feb 14 14:13:31 flight145 piaware[631]: multilateration data requested
Feb 14 14:13:31 flight145 piaware[631]: Starting multilateration client: /usr/lib/piaware/helpers/fa-mlat-client --input-connect localhost:30005 --input-type dump1090 --results beast$
Feb 14 14:13:35 flight145 piaware[631]: mlat-client(815): fa-mlat-client 0.2.8 starting up
Feb 14 14:13:35 flight145 piaware[631]: mlat-client(815): Using UDP transport to 70.42.6.198 port 6769
Feb 14 14:13:36 flight145 piaware[631]: mlat-client(815): Listening for Beast-format results connection on port 30105
Feb 14 14:13:36 flight145 piaware[631]: mlat-client(815): Listening for Extended Basestation-format results connection on port 30106
Feb 14 14:13:36 flight145 piaware[631]: mlat-client(815): Input connected to localhost:30005
Feb 14 14:13:36 flight145 piaware[631]: mlat-client(815): Input format changed to BEAST, 12MHz clock
Feb 14 14:13:37 flight145 piaware[631]: mlat-client(815): Beast-format results connection with ::1:30104: connection established
Feb 14 14:13:39 flight145 piaware[631]: mlat-client(815): Warning: the timestamps provided by your receiver do not seem to be self-consistent. This can happen if you feed data from m$
Feb 14 14:14:00 flight145 piaware[631]: 268 msgs recv’d from dump1090-mutabi; 268 msgs sent to FlightAware

11

I’m having a similar issue. I just replace dump1090 with dump1090-mutability. It seems to be running ok. However, I’m getting the following error showing in the log…


mlat-client(1138): 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.

I changed the port 30004 to 30104 during the dump1090 configuration to solve the port error I was getting.

Any idea how to solve that?