Instructions updated for v2.0-2
I’m definitely a Python 3 convert 
Now if only Raspbian had 3.4, I’d be really happy… (asyncio is the bees knees)
Worth noting that fa-mlat-client will only starts up after the FA side asks for it, which depends on where you are and what the FA servers are doing.
So if your logs say “multilateration support enabled”, but then fa-mlat-client never tries to start, that usually just means that FA doesn’t need the data yet.
What is CPU usage like over the current flightaware version? If it’s similar to that used by obj’s original client, then I’ll probably have to either run it on a different machine or offload one or more of the other feeder clients to a different machine.
sudo dpkg -i piaware_2.0-2_armhf.deb
sudo service piaware start
Those appear to possibly be redundant, dpkg -i starts the service, no need to service start a second time?
And obj, guess I have a reason to start playing with 3!
I’ve installed 2.0-2 but the version hasn’t been updated in piaware -v. It is still showing as 2.0-1.
I am planning on upgrading to a rpi2 so hopefully the cpu usage on mine will drop soon - not that it is too high now though.
It will be similar - so yeah, for busy sites, this may be an issue. I’d suggest offloading mlat-client rather than piaware as piaware really, really wants to talk to localhost (fixing that is an exercise for another day)
My post a few posts back shows top on Pi2, CPU usage is fine and a lot less than my previous Pi, a B+
OK. I already have your mlat client running on a separate pi, however that is running arch, not raspbian. Is the fa client available as a tarball, or shall I just extract the .deb?
Edit - actually I’ve found a better solution. I’m going to move the planeplotter raspberry pi client to the other pi, as that is the biggest cpu hog after dump1090. That way I can just install the piaware package as intended.
Pi B+ with Raspbian from NOOBS installed. I stopped piaware, did the install and a reboot. I get this error
[2015-05-31 20:43 BST] stop_faup1090: no need to stop faup1090, it's not running
[2015-05-31 20:43 BST] piaware (process 2243) is exiting...
[2015-05-31 20:43 BST] piaware (process 2243) is shutting down because it received a shutdown signal (SIGTERM) from the system...
[2015-05-31 20:46 BST] ADS-B data program 'dump1090-mutab' is listening on port 30005, so far so good
[2015-05-31 20:46 BST] i see dump1090-mutab serving on port 10001
[2015-05-31 20:46 BST] connecting to dump1090-mutab on port 10001...
[2015-05-31 20:46 BST] piaware is connected to dump1090-mutab on port 10001
[2015-05-31 20:46 BST] dump1090-mutab is listening for connections on FA-style port 10001
[2015-05-31 20:46 BST] 231 msgs recv'd from dump1090-mutab; 230 msgs sent to FlightAware
[2015-05-31 20:47 BST] lost connection to faup1090, reconnecting...
[2015-05-31 20:47 BST] will attempt to connect to faup1090 in 60s...
[2015-05-31 20:47 BST] piaware (process 13383) is shutting down because it received a shutdown signal (SIGTERM) from the system...
[2015-05-31 20:47 BST] stop_faup1090: no need to stop faup1090, it's not running
[2015-05-31 20:47 BST] piaware (process 13383) is exiting...
[2015-05-31 20:48 BST] ADS-B data program 'dump1090-mutab' is listening on port 30005, so far so good
[2015-05-31 20:48 BST] i see dump1090-mutab serving on port 10001
[2015-05-31 20:48 BST] connecting to dump1090-mutab on port 10001...
[2015-05-31 20:48 BST] piaware is connected to dump1090-mutab on port 10001
[2015-05-31 20:48 BST] dump1090-mutab is listening for connections on FA-style port 10001
[2015-05-31 20:48 BST] multilateration support enabled (use piaware-config to disable)
[2015-05-31 20:48 BST] multilateration data requested, enabling mlat client
[2015-05-31 20:48 BST] 214 msgs recv'd from dump1090-mutab; 134 msgs sent to FlightAware
[2015-05-31 20:49 BST] Malformed message from multilateration client ('type mlat_mlat hexid 400FBA m_short'), restarting..
[2015-05-31 20:53 BST] 2199 msgs recv'd from dump1090-mutab (1985 in last 5m); 2119 msgs sent to FlightAware
[2015-05-31 20:54 BST] got EOF from multilateration client
[2015-05-31 20:56 BST] got EOF from multilateration client
[2015-05-31 20:57 BST] Malformed message from multilateration client ('type'), restarting..
[2015-05-31 20:58 BST] 4230 msgs recv'd from dump1090-mutab (2031 in last 5m); 4150 msgs sent to FlightAware
[2015-05-31 20:59 BST] got EOF from multilateration client
[2015-05-31 20:59 BST] multilateration data no longer required, disabling mlat client
[2015-05-31 20:59 BST] multilateration support enabled (use piaware-config to disable)
[2015-05-31 20:59 BST] multilateration data requested, enabling mlat client
[2015-05-31 21:00 BST] error handling message 'type mlat_mlat hexid 40134E m_short 0' from multilateration client (37), (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-05-31 21:01 BST] Malformed message from multilateration client ('typ'), restarting..
[2015-05-31 21:03 BST] 6216 msgs recv'd from dump1090-mutab (1986 in last 5m); 6136 msgs sent to FlightAware
[2015-05-31 21:03 BST] got 'error writing "file9": broken pipe' writing to multilateration client, restarting..
It’s running OK now. I was initially getting some errors:
05/31/2015 20:26:10 mlat: fa-mlat-client 0.1.14.1 starting up
05/31/2015 20:26:10 mlat: Input connected to localhost:30005
05/31/2015 20:26:30 393 msgs recv'd from dump1090-muta; 392 msgs sent to FlightAware
05/31/2015 20:26:59 server is sending alive messages; we will expect them
05/31/2015 20:27:23 mlat: Disconnecting from localhost:30005: Lost connection to multilateration server, no need for input data
Exception BlockingIOError: BlockingIOError(11, 'write could not complete without blocking') in <_io.TextIOWrapper name='<stdout>' mode='w' encoding='ascii'> ignored
05/31/2015 20:27:28 got EOF from multilateration client
05/31/2015 20:28:30 mlat: fa-mlat-client 0.1.14.1 starting up
05/31/2015 20:28:30 mlat: Input connected to localhost:30005
05/31/2015 20:31:03 mlat: Disconnecting from localhost:30005: Lost connection to multilateration server, no need for input data
Exception BlockingIOError: BlockingIOError(11, 'write could not complete without blocking') in <_io.TextIOWrapper name='<stdout>' mode='w' encoding='ascii'> ignored
05/31/2015 20:31:09 error handling message 'type mlat_mlat hexid 3C4DD4 m_long 189b5abf5275' from multilateration client (47), (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 wi
thin
"adept send_array row"
(procedure "process_mlat_message" line 8)
invoked from within
"process_mlat_message message"), restarting..
05/31/2015 20:31:30 3973 msgs recv'd from dump1090-muta (3580 in last 5m); 3972 msgs sent to FlightAware
05/31/2015 20:32:11 mlat: fa-mlat-client 0.1.14.1 starting up
05/31/2015 20:32:11 mlat: Input connected to localhost:30005
05/31/2015 20:33:08 mlat: Disconnecting from localhost:30005: Lost connection to multilateration server, no need for input data
Exception BlockingIOError: BlockingIOError(11, 'write could not complete without blocking') in <_io.TextIOWrapper name='<stdout>' mode='w' encoding='ascii'> ignored
05/31/2015 20:33:13 error handling message 'type mlat_sync hexid 40076B m_sync 189bb455c49b' from multilateration client (47), (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 wi
thin
"adept send_array row"
(procedure "process_mlat_message" line 8)
invoked from within
"process_mlat_message message"), restarting..
05/31/2015 20:34:16 mlat: fa-mlat-client 0.1.14.1 starting up
05/31/2015 20:34:16 mlat: Input connected to localhost:30005
05/31/2015 20:34:48 mlat: Disconnecting from localhost:30005: Lost connection to multilateration server, no need for input data
Exception BlockingIOError: BlockingIOError(11, 'write could not complete without blocking') in <_io.TextIOWrapper name='<stdout>' mode='w' encoding='ascii'> ignored
05/31/2015 20:34:56 got EOF from multilateration client
This seemed to cause some quite big CPU spikes - I was seeing over 30% usage by piaware and 15-20% by fa-mlat-client.
It seems to have settled down and now I’m getting sensible output:
05/31/2015 21:12:11 mlat: fa-mlat-client 0.1.14.1 starting up
05/31/2015 21:12:11 mlat: Input connected to localhost:30005
SSL channel "sock7": error: 1433106737
05/31/2015 21:13:07 server is sending alive messages; we will expect them
05/31/2015 21:16:30 29771 msgs recv'd from dump1090-muta (2499 in last 5m); 25071 msgs sent to FlightAware
05/31/2015 21:21:30 32334 msgs recv'd from dump1090-muta (2563 in last 5m); 27634 msgs sent to FlightAware
05/31/2015 21:26:30 35019 msgs recv'd from dump1090-muta (2685 in last 5m); 30319 msgs sent to FlightAware
05/31/2015 21:27:12 mlat: Receiver connection: ready
05/31/2015 21:27:12 mlat: Server connection: ready
05/31/2015 21:27:12 mlat: Receiver: 1191.1 msg/s received 22.1kB/s from receiver
05/31/2015 21:27:12 mlat: Server: 0.0 kB/s from server 5.1kB/s TCP to server 0.0kB/s UDP to server
05/31/2015 21:27:12 mlat: Aircraft: 117 known, 40 requested by server
05/31/2015 21:31:30 37908 msgs recv'd from dump1090-muta (2889 in last 5m); 33208 msgs sent to FlightAware
05/31/2015 21:36:30 40982 msgs recv'd from dump1090-muta (3074 in last 5m); 36282 msgs sent to FlightAware
05/31/2015 21:41:30 43927 msgs recv'd from dump1090-muta (2945 in last 5m); 39227 msgs sent to FlightAware
05/31/2015 21:42:12 mlat: Receiver connection: ready
05/31/2015 21:42:12 mlat: Server connection: ready
05/31/2015 21:42:12 mlat: Receiver: 1199.2 msg/s received 22.4kB/s from receiver
05/31/2015 21:42:12 mlat: Server: 0.0 kB/s from server 5.6kB/s TCP to server 0.0kB/s UDP to server
05/31/2015 21:42:12 mlat: Aircraft: 127 known, 35 requested by server
05/31/2015 21:46:30 46595 msgs recv'd from dump1090-muta (2668 in last 5m); 41895 msgs sent to FlightAware
CPU use with those numbers is now around 17% for piaware and 12% for fa-mlat-client (on a Pi B overclocked to 1GHz). Will have to see what happens at peak times, but if cpu goes much above that then i’ll have to re-arrange things a bit to avoid running out of cpu.
Yep those errors are a sign of CPU overload, piaware shouldn’t be running that hot - taking a look…
Don’t you need a GPS for Rpi ?
I saw this weeks ago looking for some information about MLAT
I installed the beta on my secondary RPi with no issues. And I see the line in the log that says that Mlat support is enabled.
05/31/2015 22:22:53 piaware version 2.0 is running, process ID 20977
05/31/2015 22:22:53 your system info is: Linux raspberrypi 3.18.7+ #755 PREEMPT Thu Feb 12 17:14:31 GMT 2015 armv6l GNU/Linux
05/31/2015 22:22:53 connecting to FlightAware piaware.flightaware.com/1200
05/31/2015 22:22:55 FlightAware server SSL certificate validated
05/31/2015 22:22:55 encrypted session established with FlightAware
05/31/2015 22:22:56 autoUpdate in adept config is disabled, disallowing update
05/31/2015 22:22:56 manualUpdate in adept config is enabled, allowing update
**05/31/2015 22:22:56 multilateration support enabled (use piaware-config to disable)**
05/31/2015 22:22:56 ADS-B data program 'dump1090-mutab' is listening on port 30005, so far so good
05/31/2015 22:22:56 i see dump1090-mutab serving on port 10001
05/31/2015 22:22:56 connecting to dump1090-mutab on port 10001...
05/31/2015 22:22:56 piaware is connected to dump1090-mutab on port 10001
05/31/2015 22:22:56 dump1090-mutab is listening for connections on FA-style port 10001
05/31/2015 22:22:56 piaware received a message from the ADS-B source!
05/31/2015 22:22:57 logged in to FlightAware as user beckerm13
05/31/2015 22:23:06 piaware has successfully sent several msgs to FlightAware!
05/31/2015 22:23:26 157 msgs recv'd from dump1090-mutab; 60 msgs sent to FlightAware
05/31/2015 22:23:54 server is sending alive messages; we will expect them
05/31/2015 22:28:26 1722 msgs recv'd from dump1090-mutab (1565 in last 5m); 1625 msgs sent to FlightAware
However, when I use the top command I do not see the mlat-client process as shown in a previous post… Also, my Dump100-Mutability is using > 50% CPU.
Is this normal?
Marty
top - 17:34:25 up 7 days, 22:20, 1 user, load average: 0.60, 0.67, 0.71
Tasks: 75 total, 3 running, 71 sleeping, 1 stopped, 0 zombie
%Cpu(s): 48.0 us, 9.2 sy, 0.0 ni, 39.8 id, 0.0 wa, 0.0 hi, 3.0 si, 0.0 st
KiB Mem: 445740 total, 224956 used, 220784 free, 73840 buffers
KiB Swap: 102396 total, 0 used, 102396 free, 98232 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2627 pi 20 0 21084 10m 1880 R 53.7 2.5 5859:06 dump1090-mutabi
20977 root 20 0 18924 8316 4932 S 2.3 1.9 0:19.76 piaware
21688 pi 20 0 4676 2380 2012 R 1.3 0.5 0:02.99 top
7 root 20 0 0 0 0 R 0.7 0.0 38:51.65 rcu_preempt
1735 root 20 0 0 0 0 S 0.3 0.0 15:09.73 RTW_CMD_THREAD
21696 root 20 0 0 0 0 S 0.3 0.0 0:00.28 kworker/0:1
1 root 20 0 2152 1312 1208 S 0.0 0.3 0:28.77 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.33 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 13:35.69 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_sched
9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
10 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 khelper
11 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kdevtmpfs
12 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 netns
13 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 perf
14 root 20 0 0 0 0 S 0.0 0.0 0:00.61 khungtaskd
15 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 writeback
16 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 crypto
(I assume you mean for mlat)
You have to synchronize the clocks used by the receivers to measure the time of arrival.
Using a GPS-synchronized clock to timestamp the arrival time of messages is one way of doing this. This is something that e.g. the Radarcape can provide.
Merely adding a GPS to a system using an existing USB-connected dongle is not enough - the delays introduced by USB are too unpredictable, you don’t know the delay between the signal arriving and seeing the resulting samples, so even if you can use GPS time to measure when different receivers see the samples, that doesn’t tell you the time of arrival of the signal with enough accuracy. (You need an accuracy in single-digit microseconds for mlat to be useful, really)
Another way of synchronizing clocks - which is how this system works - is by using ADS-B aircraft that are transmitting positions as reference beacons.
This doesn’t require GPS.
Yes. See my earlier post.
But the GPS is pretty cool. I have the Adafruit Ulitimate Breakout v3, kernel recompiled and ntp recompiled for PPS and it does pretty good.
EDIT: I should add it is connected via UART…
I have installed piaware_2.0-2_armhf.deb on LitterBug#stats-5696 and it is up and running in Columbus Ohio.
Cheers!
LitterBug
Up and running in the Chicago area! Thanks for posting the beta opportunity.
Perfect ! Thank you!