What about the flight feeders can we be beta testers for the mlat too??
Probably in August. FlightFeeders tend to be in locations without many other feeders, so MLAT isn’t really an option yet since it requires 3-4 receivers in the area.
Up and running on my Chicago site as well!
Up and running near Sacramento on #3745. At least the Pi thinks its working. Good luck with the testing. 
Tried to extract the fa-mlat-client from the deb and run it, but it won’t start.
Replaced the python binaries in the package, but it kept complaining about some missing module at import. Guess I have to wait until the code gets released for other platforms 
Can’t it just be enabled and then when and where it works, it works.
Now we need accurate locations on our FA stats page - please assure us that FA do not show / publish these positions accurately (a 5km ‘randomness’ or rounding of longitude / latitude to 1 decimal place on publicly accessible maps etc. would be appreciated).
There is already provision for the degree of accuracy in the user control panel on your stats page
What about with multiple receivers using a merged feed (ie, if you have two Rpi, first for West sector and the second for East sector, but only one sending merged data to FA) ?
I know that the original mlat-client from Obj cannot work correctly with merged feeds, because of differents timestamps of each receivers.
So, it need to install one mlat-client per receiver.
I don’t see any mention of that here, but I think, it’s the same with the fa-mlat-client 
Got it working with some manual copying…
06/01/2015 09:32:43 piaware is connected to dump1090-muta on port 10001
06/01/2015 09:32:43 dump1090-muta is listening for connections on FA-style port 10001
06/01/2015 09:32:43 piaware received a message from the ADS-B source!
06/01/2015 09:32:45 logged in to FlightAware as user bartmellaerts
06/01/2015 09:32:45 multilateration support enabled (use piaware-config to disable)
06/01/2015 09:32:45 multilateration data requested, enabling mlat client
06/01/2015 09:32:45 mlat: fa-mlat-client 0.1.14.1 starting up
06/01/2015 09:32:45 mlat: Input connected to localhost:30005
06/01/2015 09:32:46 piaware has successfully sent several msgs to FlightAware!
06/01/2015 09:33:13 215 msgs recv'd from dump1090-muta; 170 msgs sent to FlightAware
06/01/2015 09:33:43 server is sending alive messages; we will expect them
06/01/2015 09:38:13 2191 msgs recv'd from dump1090-muta (1976 in last 5m); 2146 msgs sent to FlightAware
06/01/2015 09:43:14 4199 msgs recv'd from dump1090-muta (2008 in last 5m); 4154 msgs sent to FlightAware
06/01/2015 09:47:46 mlat: Receiver connection: ready
06/01/2015 09:47:46 mlat: Server connection: ready
06/01/2015 09:47:46 mlat: Receiver: 854.2 msg/s received 15.6kB/s from receiver
06/01/2015 09:47:46 mlat: Server: 0.0 kB/s from server 0.9kB/s TCP to server 0.0kB/s UDP to server
06/01/2015 09:47:46 mlat: Aircraft: 145 known, 6 requested by server
Yes. It’s a relatively uncommon situation but for now you’d need to run two piawares.
Cool As you probably worked out, the piaware deb bundles a virtualenv-ed copy of fa-mlat-client. This is to keep it simple for vanilla installs for the moment, and to avoid conflicts with mlat-client (as dpkg is unhappy if you try to install the same file in two different packages). Customized installs won’t work so smoothly until some more packaging work is done.
I guess it is working. Can you provide feedback if our receivers are sending you the data? My Stats page shows 2.0
Are we going to have problems running Obj’s original MLAT client alongside the PiAware Beta?
(in my case the original MLAT client is on a second Pi, the primary PiB is running the Beta … Obj can access both remotely)
just noticed the following in the log
[2015-06-01 11:53 BST] multilateration data requested, enabling mlat client
[2015-06-01 11:54 BST] multilateration data no longer required, disabling mlat client
[2015-06-01 11:56 BST] the system told us that process 22121 exited cleanly
[2015-06-01 11:56 BST] the system confirmed that process 22121 exited with an exit status of 0
[2015-06-01 11:57 BST] 109677 msgs recv'd from dump1090-mutab (2277 in last 5m); 109668 msgs sent to FlightAware
[2015-06-01 12:02 BST] 111901 msgs recv'd from dump1090-mutab (2224 in last 5m); 111892 msgs sent to FlightAware
[2015-06-01 12:07 BST] 114117 msgs recv'd from dump1090-mutab (2216 in last 5m); 114108 msgs sent to FlightAware
[2015-06-01 12:07 BST] multilateration support enabled (use piaware-config to disable)
[2015-06-01 12:07 BST] multilateration data requested, enabling mlat client
[2015-06-01 12:08 BST] got EOF from multilateration client
[2015-06-01 12:11 BST] Malformed message from multilateration client ('ty'), restarting..
[2015-06-01 12:12 BST] 116160 msgs recv'd from dump1090-mutab (2043 in last 5m); 116151 msgs sent to FlightAware
[2015-06-01 12:13 BST] error handling message 'type mlat_sync hexid 4BA90F m_sync 0a471c2ca0ce 8d4ba90f58bf035fd2145' from multilateration client (69), (not enough arguments for all format specifiers
while executing
"binary format $format {*}$row($var)"
(object "::adept" method "::fa_adept::AdeptClient::compress_array" body line 29)
invoked from within
"compress_array row"
(object "::adept" method "::fa_adept::AdeptClient::send_array" body line 7)
invoked from within
"adept send_array row"
(procedure "process_mlat_message" line 8)
invoked from within
"process_mlat_message message"), restarting..
[2015-06-01 12:15 BST] got EOF from multilateration client
[2015-06-01 12:16 BST] error handling message 'type mlat_sync hexid 405F11 m_sync 0a47a6c03891 8d405f1158b9836979cdd8f149' from multilateration client (74), (not enough arguments for all format specifiers
while executing
"binary format $format {*}$row($var)"
(object "::adept" method "::fa_adept::AdeptClient::compress_array" body line 29)
invoked from within
"compress_array row"
(object "::adept" method "::fa_adept::AdeptClient::send_array" body line 7)
invoked from within
"adept send_array row"
(procedure "process_mlat_message" line 8)
invoked from within
"process_mlat_message message"), restarting..
[2015-06-01 12:17 BST] 118084 msgs recv'd from dump1090-mutab (1924 in last 5m); 118075 msgs sent to FlightAware
[2015-06-01 12:18 BST] got EOF from multilateration client
[2015-06-01 12:19 BST] multilateration data no longer required, disabling mlat client
[2015-06-01 12:22 BST] 120176 msgs recv'd from dump1090-mutab (2092 in last 5m); 120167 msgs sent to FlightAware
If you have enough CPU spare it should be fine.
This is CPU overload; piaware is not keeping up with the traffic from fa-mlat-client. Working on it…
doesn’t look that busy (This is an original PiB 512Mb) - but it’s early days for the beta
top - 12:07:47 up 10 days, 22:29, 1 user, load average: 1.05, 0.91, 0.98
Tasks: 66 total, 3 running, 63 sleeping, 0 stopped, 0 zombie
%Cpu(s): 55.0 us, 16.9 sy, 0.0 ni, 21.9 id, 0.0 wa, 0.0 hi, 6.3 si, 0.0 st
KiB Mem: 445740 total, 237144 used, 208596 free, 80808 buffers
KiB Swap: 102396 total, 0 used, 102396 free, 100788 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1841 dump1090 15 -5 19900 10m 1936 R 50.8 2.5 6596:48 dump1090-mutabi
22301 root 20 0 72844 6456 3388 S 10.7 1.4 0:02.79 fr24feed
16385 root 20 0 90368 7476 2796 S 10.4 1.7 165:09.51 pfclient
21845 root 20 0 18836 8284 4924 S 3.6 1.9 12:03.80 piaware
22329 pi 20 0 4672 2496 2136 R 1.0 0.6 0:00.30 top
7 root 20 0 0 0 0 R 0.7 0.0 50:20.46 rcu_preempt
I’m seeing the following in the piaware.out log…
06/01/2015 12:45:13 mlat: Input connected to localhost:30005
06/01/2015 12:45:13 mlat: Unexpected exception on connection to localhost:30005
Traceback (most recent call last):
File "/usr/lib/python3.2/asyncore.py", line 83, in read
obj.handle_read_event()
File "/usr/lib/python3.2/asyncore.py", line 449, in handle_read_event
self.handle_read()
File "/usr/lib/fa-mlat-client/lib/python3/dist-packages/mlat/client/receiver.py", line 128, in handle_read
consumed, messages = self.packetize(moredata, self.last_timestamp)
_modes.ClockResetError: Out of range timestamp seen
06/01/2015 12:45:13 mlat: Lost connection to localhost:30005
06/01/2015 12:45:13 mlat: Reconnecting in 30.0 seconds
It seems the exception is time related but checked the system’s time and ntpq and I don’t see an issue. I can nc the 30005 stream and it is available. Relevant processes…
dump1090-mutability --quiet --net --gain -10 --device-index 01000580 --ppm 58
dump1090-mutability --device-index 02000360 --ppm 36 --net --gain -10 --quiet --net-fatsv-port 11001 --net-sbs-port 33003 --net-ro-port 0 --net-ri-port 0 --net-bo-port 33005 --net-bi-port 0 --net-http-port 8088
/usr/bin/piaware -p /var/run/piaware.pid
/usr/lib/fa-mlat-client/bin/python3.2 /usr/bin/fa-mlat-client --input-host localhost --input-port 30005
Operator error? Something unique about the setup? Normal?
It won’t currently work with a merged feed, it can’t separate out the timestamps of the two receivers…