Piaware has recently added the capability of doing MLAT processing, I decided to see if I could get this working with my modesmixer2 setup that is receiving serial over USB data from a Mode-S Beast receiver rather than than a dongle using dump1090. That setup is working very well, feeding data to the PlanePlotter servers via modesmixer2 and ppup1090 on port 30005.
The basic flow of the new Piaware MLAT system is here:
My current modesmixer2 invocation is with:
modesmixer2 --inSerial /dev/ttyUSB0:3000000:hardware --outServer beast:30005 --web 8080 --location yy.yyyyyy:-xx.xxxxxx
This simply receives serial data (already decoded) in Beast binary format on USB serial port ttyUSB0 and translates it to an output on port 30005. I also start the web server and provide my location for modesmixer web page plotting of my coverage and stats and for more efficient position decoding.
Piaware used to have problems receiving data for normal position reporting on port 30005 from modesmixer2, even though that was the same port used by the expected dump1090 decoder application. However, that issue seems to have been resolved with the latest MLAT-capable version of Piaware. piaware_2.1-2_armhf.deb.
Here are the relevant piaware log messages showing things are starting up just fine with modesmixer2:
07/27/2015 01:36:41 ADS-B data program 'modesmixer2' is listening on port 30005, so far so good 07/27/2015 01:36:41 Starting faup1090: /usr/bin/faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --lat 41.911 --lon -88.357 07/27/2015 01:36:41 Started faup1090 (pid 2311) to connect to modesmixer2 07/27/2015 01:36:41 logged in to FlightAware as user donf99 07/27/2015 01:36:41 multilateration support enabled (use piaware-config to disable) 07/27/2015 01:36:41 multilateration data requested, enabling mlat client 07/27/2015 01:36:41 Starting multilateration client: /usr/lib/fa-mlat-client/fa-mlat-client --input-connect localhost:30005 --udp-transport 22.214.171.124:6288:4111205693 07/27/2015 01:36:45 piaware received a message from modesmixer2! 07/27/2015 01:36:45 piaware has successfully sent several msgs to FlightAware! 07/27/2015 01:36:46 mlat(2313): fa-mlat-client 0.2.3 starting up 07/27/2015 01:36:46 mlat(2313): Using UDP transport to 126.96.36.199:6288 07/27/2015 01:36:46 mlat(2313): Input connected to localhost:30005 07/27/2015 01:37:11 141 msgs recv'd from modesmixer2; 141 msgs sent to FlightAware 07/27/2015 01:37:59 server is sending alive messages; we will expect them 07/27/2015 01:42:11 1972 msgs recv'd from modesmixer2 (1831 in last 5m); 1972 msgs sent to FlightAware 07/27/2015 01:47:11 3874 msgs recv'd from modesmixer2 (1902 in last 5m); 3874 msgs sent to FlightAware 07/27/2015 01:51:46 mlat(2313): Receiver connection: ready 07/27/2015 01:51:46 mlat(2313): Server connection: ready 07/27/2015 01:51:46 mlat(2313): Receiver: 942.3 msg/s received 15.7kB/s from receiver 07/27/2015 01:51:46 mlat(2313): Server: 2.7 kB/s from server 0.0kB/s TCP to server 10.0kB/s UDP to server 07/27/2015 01:51:46 mlat(2313): Results: 1259.9 positions/minute 07/27/2015 01:51:46 mlat(2313): Aircraft: 140 known, 132 requested by server 07/27/2015 01:52:11 5746 msgs recv'd from modesmixer2 (1872 in last 5m); 5746 msgs sent to FlightAware
If you examine the FlightAware flow disgram, you will see that normal sharing data is received from modesmixer2 on port 30005, the same port used by PlanePlotter and ppup1090 for autonomous uploading to PlanePlotter servers. However, Piaware also has a back-channel on port 30004 that Piaware normally uses to send MLAT positions back to input port 30004 on dump1090 in Beast binary format. Dump1090 can display the MLAT positions on its own web server with distinct color coding.
MLAT on Piaware can be enabled with or with out the backchannel for reporting Piawares own MLAT positions with the configuration command:
piaware-config -mlat 0/1 (enables/disables MLAT processing. Starts the MLAT process if request received from Flightaware servers.)
piaware-config -mlatResults 0/1 (enables/disables sendin MLAT position data on port 30004.)
piaware-config -mlatResultsFormat formatlist (Poorly documented. Seems to allow afjusting MLAT data on 30004 in other than Beat binary.)
I tried enabling reception of the MLAT data in modesmixer 2 by defining an additional input with this invocation:
modesmixer2 --inSerial /dev/ttyUSB0:3000000:hardware --inConnect 127.0.0.1:30004 --outServer beast:30005 --web 8080 --location yy.yyyyyy:-xx.xxxxxx
However, when I enable the MLAT back channel on Piaware, I receive port 30004 “Connction Refused” errors in both the modes2mixer web page log and the Piaware log.
It seems modesmixer2 should be able to detect the secondary position reports on port 30004, as they are in the common Beast binary format, according to documentation on Piaware.
Has anyone come up with a way of combining the Piaware MLAT positions in the output stream of modesmixer2?
Thanks and regards,